Introduzione al Project Management

Piero Schiavo Campo

Introduzione al
Project Management

Concetti base e
definizioni

Progetto
 Qualsiasi attività individuale o collettiva che punti al
raggiungimento di un risultato definito e che comporti
l’esecuzione di una serie di passi individuabili in qualche
modo

 Un progetto richiede:
 Pianificazione
 Budget
 Tempo
 Risorse
 Meccanismi di controllo

Piero Schiavo Campo – Introduzione al Project e Risk Management - 3

Il Project Management e Risk Management
 Project Management: insieme di tecniche e metodologie
elaborate nel corso di anni sulla base di esperienze pratiche,
che puntano a ottimizzare le fasi di pianificazione e
controllo del progetto

 Risk Management: metodologie e tecniche necessarie per
individuare i rischi, prevenirli (se possibile) o comunque
minimizzare il danno che ne può derivare

 I due aspetti sono intrinsecamente connessi tra loro


Devo appendere un quadro (1)
 Pianificazione:
 Lo appendo domenica, perché prima non ho tempo
 Mi servono i chiodi; li compro sabato
 L’unica risorsa sono io
 Per comprare i chiodi basta un euro


 Controllo
 Bisogna che il quadro sia diritto; dopo averlo appeso devo usare un filo
a piombo
 I chiodi si vendono solo in confezioni da 100 che costano 2,5 euro (ho
sforato il budget)
 Ha nevicato tutta la notte e ho passato la mattina di domenica a
spalare la neve; bisogna che ripianifichi l’operazione (ho sforato i
tempi)
 La scala traballa, e bisogna che mio figlio la tenga ferma (risorsa extra)


 Rischi
 Nel piantare il chiodo potrei bucare una canalina elettrica
 Il chiodo potrebbe finire nell’interstizio tra due mattoni
 Il martello potrebbe cadermi di mano, e danneggiare il pavimento
 ....


Note sui rischi
 Ciascun rischio ha una probabilità di verificarsi e una gravità
del danno che ne può conseguire

 La valutazione dei rischi fa evidentemente parte della fase di
pianificazione. Ad esempio posso picchiare sul muro prima
di piantare il chiodo per vedere se suona a vuoto (devo
pianificare l’operazione)


I casi non banali
 Nella maggior parte dei progetti reali la pianificazione, il
controllo e l’analisi dei rischi non possono procedere in
modo “istintivo”
 Nel caso del quadro, ho sforato il budget del 250%; cosa succede se
sforo di altrettanto nel progetto di costruzione di un edificio?
 Se buco la canalina elettrica di casa mia faccio un danno; cosa succede
se nello scavare le fondamenta di un edificio trancio un cavo elettrico
portante? Se quel cavo alimenta un ospedale?


Vincoli
 Tempi
 Quasi tutti i progetti comportano obiettivi che hanno senso purché
vengano realizzati entro tempi determinati

 Costi
 Quasi tutti i progetti devono tenere conto di vincoli di budget

 Qualità
 La “qualità assoluta” non è raggiungibile
 Quello che occorre è che la qualità del prodotto rispetti i requisiti
dichiarati


Il modo standard di procedere
 Top-down:
 Individuo i singoli aspetti rilevanti nel problema
 Li analizzo; cerco di scomporli in sotto-aspetti
 Porto avanti il processo finché gli elementi non sono suscettibili di
un’analisi dettagliata

 Si basa su un’ipotesi di fondo di tipo riduzionista


La grande novità del 2004
 A partire dal 2004 il mondo del Web ha subito una generale
trasformazione nota come Web 2.0

 Il termine è stato lanciato dalla prima O’Reilly Media Web
2.0 Conference (Ottobre 2004)

 L’atteggiamento generale “2.0” ha avuto impatti immediati
sulla filosofia di gestione dell’azienda (Enterprise 2.0)

 In particolare, sulla gestione dei progetti


Enterprise 2.0
 Il processo generale alla base del Web 2.0 è di tipo bottom-
up
 Non c’è nulla di centralizzato; tutto procede dal basso

 Qualunque cosa voglia dire, il “Project Management 2.0” è
in conflitto con l’atteggiamento finora dominante
 Se resta “2.0” non può essere top-down
 Se pretende di restare top-down non può essere “2.0”


2.

LA PIANIFICAZIONE DEL PROGETTO

La WBS
 Work Breakdown Structure
 Scomposizione del progetto nei suoi elementi costitutivi
 Struttura ad albero
 I nodi prendono il nome di Work Package (WP)
 I nodi di livello finale (foglie) prendono il nome di Task

 Nota: per alcuni WP e Task sono sinonimi

Piero Schiavo Campo –dei progetti – 1. Il Project Management
La gestione Introduzione al Project e Risk Management - 15

WBS – Un esempio


La WBS come modello del progetto
 Il modello (e la sua granularità) dipendono dalle esigenze
specifiche

 Non c’è un’unica WBS possibile

 E’ meglio produrre diverse WBS, per “modellare” il
problema in modi diversi


Informazioni associate a ogni task
 Descrizione (cosa si deve fare)
 Responsabile (chi risponderà)
 Centro di costo (chi paga)
 Costo (quanto costa)
 Input (cosa serve per realizzarlo)
 Output (cosa deve produrre)
 Tempi (quando si realizza)
 Attività (come si realizza)


Organization Breakdown Structure
 Scomposizione gerarchica delle responsabilità di progetto
 Individuare univocamente i responsabili dei WP e i
meccanismi di riporto

Piero Schiavo Campo –dei progetti – 1. Il Project Management
La gestione Introduzione al Project e Risk Management - 19

Matrice delle responsabilità (esempio)


Collegamento tra WBS e OBS


Lo sviluppo temporale del progetto
 Diagramma di Gannt
 Nella sua forma originale (statica) è in disuso
 Si utilizza la tecnica del Critical Path (CPM), che permette di avere
diagrammi di Gannt dinamici

 Diagramma di Pert (solo per progetti molto innovativi,
quando risulta impossibile un calcolo “preciso” di tempi,
costi ecc.)


Un esempio di Gannt


Gannt: quando e come
 Va molto bene per descrivere macro attività, ma perde di
efficacia se le attività sono molte o troppo di dettaglio

 Sotto-gannt (attenzione: un unico punto di ingresso e un
unico punto di uscita!)


Tecniche reticolari
 Utilizzano algoritmi e concetti sviluppati nel contesto della
teoria dei grafi

 Vengono analizzate le singole attività dal punto di vista delle
dipendenze

 (NB: i box non sempre coincidono con i WP!)


Dipendenze


Milestone
 Sono “attività evento” di durata nulla

 Sono associate a specifici momenti nel corso del progetto
(consegne parziali, momenti di verifica…)

 Si utilizzano nel gannt come normali attività


Legami
 Le dipendenze definiscono legami tra le attività

 Ogni legame ha una durata, eventualmente nulla


Metodo CPM
 Critical Path Method: basato sulle criticità temporali
 Durata deterministica delle attività
 Individua gli scorrimenti possibili per le attività
 Individua inizio e fine del progetto
 Individua il cammino critico
 Determina il gannt di progetto in modo dinamico


Scorrimenti e criticità


Cammino critico (Critical Path)
 E’ definito dall’insieme delle attività critiche
 Si può dimostrare che è unico


Come gestire il gannt concretamente
 Esistono diversi prodotti software che permettono
 Di definire la WBS
 Di specificare le dipendenze tra i task
 Di associare ai task tempi, costi e risorse
 Di costruire automaticamente il CP
 Di misurare l’avanzamento in corso d’opera e eventualmente ridefinire
il CP
 ...

 Il più noto è MS Project


Pianificazione dei deliverables
 Sono i prodotti di ciascuna attività (WP o task)
 Il loro rilascio è pianificato insieme alle attività (milestone) o per
scadenze fisse
 Possono essere descritti dal piano di qualità (tipologia)
 Attribuendo un peso ai deliverables, si tiene sotto controllo
l’avanzamento percentuale dei lavori


Pianificazione delle risorse
 Individuazione delle disponibilità per ciascuna risorsa

 Valutazione dei carichi di lavoro e livellamento

 Valutazione delle eventuali criticità

 Valutazione dei profili psicologici e degli skill


Calcolo del carico delle risorse


Livellamento a “tempi limitati”


Livellamento a “risorse limitate”


Pianificazione dei costi
 Viene fatta a vari livelli
 Strategico: budget aziendale
 Di massima (sulla WBS)
 Di dettaglio (per attività/responsabile)

 Permette di
 Anticipare i costi di progetto
 Impostare il cash flow
 Impostare le verifiche di avanzamento


Pianificazione strategica
 Costo massimo di progetto, risultato della strategia
aziendale

 Assegnato alla radice della WBS

 E’ il termine di paragone per pianificazioni di dettaglio


Pianificazione di massima
 Budget assegnato ad ogni WP

 Viene consolidato sugli elementi di livello superiore della
WBS

 Il totale alla radice dà il costo di massima, da confrontare
con il budget strategico


Pianificazione di dettaglio
 Individuazione dei costi al livello più disaggregato

 Lista dei costi a fronte di ciascuna attività del reticolo di
progetto

 Si usa spesso la CBS (Cost Breakdown Structure)


CBS


Curva di budget del progetto


Curva di budget delle attività


Pianificazione dei ricavi


Cash flow di progetto


Il controllo di progetto
 Evidenziazione di
 Ritardi / anticipi (scostamento tra le date previste e quelle effettive)
 Variazioni economiche dell'andamento del progetto
 Impegni sostenuti dalle risorse e risultati raggiunti

 Esecuzione delle stime a finire

 Analisi ed attivazione di possibili azioni di rimedio
 Individuazione e valutazione dei problemi
 Rivisitazione delle priorità
 Valutazione delle alternative


Metodi di rilevazione (1)
 Rilevazione dei tempi
 A date e durate rimanenti
 A percentuale di completamento temporale

 Rilevazione delle risorse
 Tramite dichiarazione del tempo speso su attività (Timesheet -
rilevazione giornaliera)
 Tramite dichiarazione della percentuale del lavoro svolto


Metodi di rilevazione (2)
 Rilevazione dei costi
 Metodo dell'avanzamento contabile (rilevazione dei costi
effettivamente sostenuti)
 Metodo dell'avanzamento fisico (rilevazione della percentuale di
avanzamento fisico)

 Misura delle performance
 Metodo dell'Earned Value (rilevazione della percentuale fisica di
completamento)


Earned Value - Definizione
 Budget value: costo programmato all’inizio del progetto

 Actual value: costo effettivo sostenuto

 Earned value: quota del costo di budget sostenuto


Earned Value - Calcolo
 Per le attività completate
 La “quota del costo di budget” equivale al budget di attività

 Per le attività non completate (in corso d’opera)
 La “quota del costo di budget” è pari al budget dell’attività moltiplicato
per la percentuale di avanzamento

 (il problema è misurare la percentuale di avanzamento)


Misure della percentuale di avanzamento (1)
 ON / OFF (anche detta 0 / 100)
 L'avanzamento vale 0 dall'inizio dell'attività, passa a 100 al termine.
Utile per attività di breve durata o di basso impatto economico.

 50 / 50 (20 / 80)
 L'avanzamento vale 50 (20) dall'inizio dell'attività, passa a 100 al
termine.
Utile per attività di breve durata o di basso impatto economico.

 Eventi ponderati
 Vengono individuati alcuni eventi importanti all'interno dell'attività e a
ciascuno viene dato un peso (normalizzato a 100). Il raggiungimento di
un evento partecipa per il suo peso all'avanzamento dell'attività.
Applicabile a tutte le attività in cui sono evidenziabili delle sottoparti.


Misure della percentuale di avanzamento (2)
 Numero di unità finite
 Viene individuato il totale di prodotto nell'attività espresso per
quantità omogenee. Il numero di unità realizzate sul totale fornisce
l'avanzamento dell'attività. Applicabile solo per attività misurabili in
quantità

 Output proporzionale all'input
 Viene individuata la quantità totale di unità necessarie all'attività. La
misurazione delle quantità consumate sul totale determina
l'avanzamento dell'attività. Applicabile ad attività che fanno uso di
materiali, ma anche a risorse umane.


4.

I RISCHI DI PROGETTO –
UN ESEMPIO REALE

Una case history catastrofica
 Il caso di Ashton-Tate (anni ’80) e il progetto dBase IV
 Spesso si impara di più dagli errori che dai successi…


Vulcan
 Alla fine degli anni ’70 Wayne Ratliff, un guru
dell’informatica americana, scrive da solo il programma
Vulcan

 Il nome si deve alla sua passione per la serie televisiva Star
Treck

 E’ il primo (all’epoca unico) programma per la gestione di
database relazionali su PC

Piero Schiavo Campo – Introduzione al Project e il rischio di progetto - 57
La gestione dei progetti – 2. Affrontare e gestire Risk Management

Cosa fa Vulcan
 E’ scritto in linguaggio Assembler (la cosa è importante,
come si vedrà)

 E’ di fatto un linguaggio di programmazione orientato alla
gestione di tabelle db

 E’ un linguaggio interpretato


Ashton Tate
 Nasce nel 1980

 Fin dall’inizio acquisisce tutti i diritti su Vulcan, che viene
messo in commercio con il nome di dBase II

 Il programma ha un successo strepitoso (anche perché
all’epoca è l’unico software disponibile della sua classe)

 E’ poverissimo dal punto di vista dell’interfaccia utente


dBase III
 dBase II viene completamente riscritto in linguaggio C; nasce
dBase III, che poi diventerà dBase III plus

 Ashton Tate distribuisce anche altri prodotti (Framework,
Multimate...), ma il suo successo è essenzialmente legato
alla linea dBase

 Nel 1984 Ashton Tate fattura 35 M$, Microsoft fattura 55 M$

 Alla metà degli anni ottanta AT è la terza software house del
mondo, dopo Microsoft e Lotus


Clipper
 Verso la metà degli anni 80 appare finalmente un
competitor: si chiama Clipper

 E’ solo un compilatore per il linguaggio dBase, non dispone
di funzionalità utente (creazione di maschere, query...)

 E’ un vero compilatore, quindi è molto più veloce di dBase


Viene annunciato dBase IV
 Ashton Tate deve reagire

 Nel 1987 annuncia che verrà lanciato dBase IV in versione
multilingua (inglese, italiano, francese, tedesco, olandese)

 Il programma è previsto per la primavera del 1988

 Centinaia di migliaia di sviluppatori dBase in tutto il mondo
sono in trepida attesa


Cosa farà dBase IV
 Dovrà superare (o per lo meno pareggiare) la velocità di
Clipper

 Dovrà disporre di potenti funzionalità utente (quelle che
mancavano sia a Clipper sia alle precedenti versioni di
dBase)
 Impostazione delle tabelle
 Creazione di relazioni
 Creazione di maschere
 Query
 Eccetera


dBase III è un ramo morto
 Il programma deve essere completamente riscritto

 Le funzionalità utente sono del tutto nuove

 La cosa giusta sarebbe partire dal codice di dBase II, molto
più piccolo e maneggevole


Reverse engeneering
 Ma dBase II è scritto in linguaggio Assembler! (difficile da
manutenere, impossibile da portare...)

 Ashton Tate decide di generare il “nocciolo” del codice del
nuovo programma con la tecnica del “reverse engeneering”

 In pratica si tratta di un programma che legge il codice
Assembler e lo converte in C


Problemi
 Lo sviluppo delle nuove funzionalità e del compilatore
iniziano a partire dal codice così generato

 Ben presto ci si accorge che il codice è disottimizzato: non si
riesce a far girare il programma avendo a disposizione al
massimo 640 K di memoria (così funzionavano i computer
dell’epoca)


I problemi si propagano
 Invece di accettare un ritardo secco di qualche mese (che
sarebbe comportato dalla riscrittura ex novo in C del
nocciolo del programma), AT cerca di rimediare in qualche
modo

 La produzione del codice subisce continui ritardi

 Questo fatto ha effetti sull’intera WBS

 dBase IV cresce come un palazzo di cui siano franate le
fondamenta


La catastrofe
 dBase IV esce nella primavera del 1989, con un anno di
ritardo sull’annuncio (nel frattempo moltissimi utenti sono
passati a Clipper)

 Non è affatto più veloce di dBase III

 Nella prima versione è pieno di bachi, e praticamente
inutilizzabile


La fine
 Ashton Tate resiste sul mercato per un anno circa, poi viene
comprata da Borland

 Borland porta avanti senza entusiasmo la linea dBase, con
versioni Macintosh e Windows

 L’avvento di Paradox e poi di Access portano di fatto alla
morte di dBase


Domande
 Dove ha sbagliato Ashton Tate?
 Come mai l’errore è stato così catastrofico?
 C’era modo di evitalo?
 Si potevano ridurre i danni?


Strutture ad albero
Progetto

WP1 WP2 WP3 WP4

WP11 WP12 WP13 WP41 WP42

WP121 WP122


Modello - Struttura regolare
 Ci sono n sottonodi per ogni nodo
 Tutti i livelli sono occupati fino al livello L

Livello 0 Nodi “foglia”: Nf nL
Livello 1
Nodi totali:
nL 1 1
Livello 2 Nt
n 1
Livello 0

Livello 1
Livello 2
Livello 3

Piero Schiavo Campo – Introduzione al Project e il rischio di progetto - 72
La gestione dei progetti – 2. Affrontare e gestire Risk Management

Quanto è probabile che nascano problemi?
 Il numero di WP cresce esponenzialmente con il crescere dei
livelli

 Supponiamo che ci sia una probabilità costante che un WP
“vada male”
 (si sforano i tempi, i costi, la qualità non è quella attesa, ecc.)

 Qual è la probabilità che qualcosa vada male nell’intero
progetto?


Probabilità di “problemi” nel progetto
Numero di blocchi

Probabilità di "errore" in un blocco
50 100 150 200 250

0,5% 22,2% 39,4% 52,9% 63,3% 71,4%

1,0% 39,5% 63,4% 77,9% 86,6% 91,9%

1,5% 53,0% 77,9% 89,6% 95,1% 97,7%

2,0% 63,6% 86,7% 95,2% 98,2% 99,4%

2,5% 71,8% 92,0% 97,8% 99,4% 99,8%


Propagazione del rischio
 Più che sulla WBS, conviene basarsi sulla mappa delle
dipendenze

 Dipendenze troppo profonde e ramificate aumentano la
probabilità che larghe parti del progetto non rispettino i
requisiti

 Se non è possibile modificare le dipendenze, occorre
prestare la massima attenzione ai nodi di alto livello


Note sul caso dBase
 L’errore fondamentale (l’uso del reverse engeneering) è alla
radice del processo di sviluppo, dunque catastrofico

 Era un errore “fattibile”
 Nell’88 si era arrivati ai 486 su computer di classe AT. Le ram
arrivavano a 614 KB. dBase II era uscito nell’81 su computer di classe
PC, con memorie massime di 128 KB. NESSUNO avrebbe potuto
immaginare che il codice generato a macchina non fosse compilabile
su un computer di 7 anni dopo, per quanto disottimizzato potesse
essere.

 Era un errore evitabile
 Bastava fare dei test prima di partire con il piano di progetto! (ma a
nessuno venne in mente)


5.

LA GESTIONE DEL RISCHIO DI
PROGETTO

Definizione di “rischio”
 Conseguenza di un evento che può verificarsi con una certa
probabilità
 nota
 ignota
 stimabile in qualche modo


Rischi puri
 Corrispondono ad eventi che, se si verificano, creano un
danno certo (minacce)
 Si verifica il crollo di un’impalcatura nel cantiere
 Un nostro partner subisce un tracollo economico ed è costretto a
chiudere
 Un personaggio chiave nel progetto dà improvvisamente le dimissioni
 eccetera


Rischi speculativi
 Corrispondono ad eventi che, se si verificano, possono
creare un danno oppure un vantaggio (opportunità)
 I costi di progetto dipendono in modo determinante dal prezzo del
greggio, che potrebbe salire, ma anche scendere
 Il committente paga in dollari (il cambio finora tende a salire, ma
potrebbe anche invertire la tendenza)
 Eccetera

 Nel seguito ci concentreremo sui rischi puri


Classi di rischi
 Economici
 impattano in senso negativo sui costi di progetto

 Di tempo
 comportano ritardi nella consegna finale

 Di qualità
 comportano un abbassamento della qualità finale (per essere più
precisi: comportano il fatto che l’”oggetto finale” non corrisponde ai
requisiti di qualità)


I rischi impattano (spesso) sull’intero progetto
 Un incendio in un magazzino comporta:
 Danni economici diretti
 Impatti sui tempi di progetto (se occorre perdere tempo per rifornirsi
nuovamente)
 Impatti sulla qualità (se quello che è andato distrutto ha costi che
l’azienda non è più disposta a sostenere, e si decide di abbassare il
livello qualitativo)
 Impatti sull’organizzazione del progetto (i rifornimenti devono essere
effettuati utilizzando un magazzino molto più distante dalla sede del
lavoro)


Il processo di gestione del rischio
 Identificazione
 Individuazione delle tipologie di eventi rischiosi

 Quantificazione
 Valutazione quantitativa degli effetti e delle ricadute sul progetto dei
rischi individuati

 Pianificazione
 Individuazione delle azioni da mettere in atto per prevenire il rischio (o
per limitarne le conseguenze)


Quali rischi? Quanti rischi?
 Non è possibile prevedere in anticipo tutto ciò che potrà
capitare nel corso del progetto
 Incendi
 Furti
 Malattie
 Scioperi prolungati
 ....

 In generale l’informazione che possiamo avere non è
completa


Progetti innovativi
 Rispetto all’identificazione dei rischi bisogna distinguere tra
progetti “standard” e progetti innovativi

 Progetti standard:
 Un nuovo cantiere per un’impresa edile
 Una nuova consulenza per un’azienda di consulenza
 Un nuovo progetto software per una software house
 ...

 Ogni progetto comporta (di solito) un certo grado di
innovazione


Cause e effetti
 Ci sono due modalità possibili per l’individuazione dei rischi:

a) Partire dalle cause (eventi che possono generare situazioni di rischio)
e individuarne le conseguenze
b) Partire dagli effetti (situazioni che possono creare problemi al
progetto) e individuarne le premesse

 La tecnica migliore è un misto delle due

a) → Funziona meglio per identificare i rischi
b) → Funziona meglio per identificare le opportunità


Diagramma di Ishikawa
 Si cerca di identificare e ordinare in modo strutturato tutte
le possibili cause che portano a un determinato effetto o
problema

 Viene anche chiamato diagramma a lisca di pesce, per la
sua tipica forma


Procedimento
 L’effetto (il problema) viene scritto a destra. Da esso si
dirama, verso sinistra, una sorta di albero

 I rami dell’albero rappresentano le classi di cause possibili
che portano a quell’effetto

 All’interno delle categorie di cause vengono scritte le cause
specifiche che possono portare al problema (i rami
secondari dell’albero) alle quali si può aggiungere un
ulteriore sottolivello


Esempio: la mensa dell’Università

Personale Menù
Scontroso
Manca un cuoco di livello Piatti presentati male

Poco motivato
Materie prime scadenti Problema:
Sottodimensionato
le valutazioni degli
studenti e del
Scarsa pulizia
personale sono
Sottodimensionato molto basse
Saloni “vecchi”

Ambiente


Analisi di Pareto
 Si basa sulla constatazione macro-economica, fatta nel 1895
dall’economista Vilfredo Pareto, che una minima parte della
popolazione possiede la maggior parte delle ricchezze, e
viceversa

 Generalizzando, la legge di Pareto può essere tradotta con
la seguente considerazione: in moltissimi sistemi una
piccola parte delle cause determina la maggior parte delle
conseguenze, e viceversa


Utilizzo pratico
 La rappresentazione di questo fenomeno, in forma di curva,
assume la sua importanza in quanto può essere usata per
rappresentare numerosi fenomeni di concentrazione o
ripartizione

 In particolare viene utilizzata per rappresentare il rapporto
tra variabili di input (cause) e variabili di output
(conseguenze) in modo da evidenziare le poche cause
critiche rispetto alle molte cause non critiche


Esempio

70 100,00%

90,00%
60
80,00%

50 70,00%
Numero dei reclami

% dei reclami
60,00%
40
Numero reclami
50,00%
% cumulata
30
40,00%

20 30,00%

20,00%
10
10,00%

0 0,00%
Ritardo nella Consegnati Consegnati Fatturazione Consegna non
consegna prodotti sbagliati prodotti difettosi errata avvenuta
Cause dei reclami


Nota
 Prendere in considerazione pochi rischi può portare a danni
imprevisti

 Prenderne in considerazione troppi aumenta i costi di
gestione del progetto


Partire dalla WBS
 La WBS è un modello del progetto

 All’interno della WBS è possibile identificare singoli blocchi
sottoposti a minacce

→ Analizzare la WBS fino al livello in cui i rischi si presentano come ben
definiti e identificabili

 Attenzione: i danni possono propagarsi da un WP ad un
altro!


Unità di rischio
 Definiamo unità di rischio una qualsiasi entità, individuata a
partire dalla WBS, soggetta a rischi identificabili e omogenei


Matrice Unità di rischio – Minacce
 Identificare le (principali) minacce a cui è esposta ciascuna
unità di rischio
 Purtroppo non c’è un metodo analitico (top-down) che
permetta di farlo

Allagamento
Vandalismo
Infortunio

Incendio
Guasto
Furto
Personale 
Cabina elettrica    
Magazzino
Container  
Ricambi   
Mezzi
Movimentazione   
Sollevamento  


Diagramma di contesto

S
S

F
F S

Dipendenza
F
Influenza
S Controllo
F
F
F
F Fattori

Bournett e Youker 1980, Archibald 2000 S Soggetti


Fattori e soggetti
 Fattori: Elementi esterni che possono creare rischi o
opportunità
 Modifiche della normativa fiscale
 Agenti atmosferici
 Livello di affidabilità del cliente
 …

 Soggetti: Entità esterne che possono interferire nel progetto
 Un fornitore
 Un concorrente
 Il nostro capo
 …


Controllo, dipendenza, influenza
 Controllo: Possiamo intervenire con una probabilità di
raggiungere il risultato pari al 100%

 Influenza: Possiamo intervenire, ma la probabilità di
raggiungere il risultato è minore del 100%
(convenzionalmente = 50%)

 Dipendenza: Non abbiamo nessun modo per intervenire


Diagramma di contesto (Nota)
 Citato anche in senso “generico”

(esempi presi dal Web)

La gestione dei progetti – 2. Affrontare e gestire il rischio di progetto

Tecniche “creative”
 Brainstorming
 Discussione libera (6 – 10 partecipanti)
 Scopo: fare emergere le idee e raggiungere un momento di sintesi

 Metodo sinettico (Invention Group di Harvard, anni ’60)
 Ogni partecipante è tenuto a generare un certo numero (25 – 35) di
idee “varie” sul problema

 Mind mapping


Mind mapping

(esempi presi dal Web)


Matrice di esposizione al rischio
 (Risk exposure matrix)

 Mette a confronto le probabilità di accadimento degli eventi
e gli impatti attesi

 Si basa sull’idea che entrambe queste variabili concorrono
alla definizione della “gravità del rischio”

 Ha lo scopo di mettere in evidenza gli eventi critici

 Può essere semplicemente qualitativa, oppure associata a
misure (per lo più “euristiche”)


Matrice di esposizione al rischio – Qualitativa
Probabilità

Molto bassa
Molto alta

Bassa
Media
Alta
Catastrofico A

Critico B
C
Impatto

Consistente D

Marginale E F
G

Trascurabile H

Eventi


Livelli di esposizione al rischio
Probabilità

Molto bassa
Molto alta

Bassa
Media
Alta
Catastrofico

Critico
Impatto

Consistente

Marginale

Trascurabile

Elevato
Intenso
Limitato
Modesto


Soglia di attenzione
Probabilità

Molto bassa
Molto alta

Bassa
Media
Alta
Catastrofico

Critico
Impatto

Consistente

Marginale

Trascurabile


Matrice di esposizione al rischio – Note
 Spesso entrambe le misure sono “euristiche” (non sappiamo
veramente misurare né le probabilità né gli impatti)

 Visto che lo scopo è di tipo “on-off” (l’evento è critico o no),
c’è il problema degli eventi che si collocano a cavallo di due
categorie

 Non è un problema banale:
 includere troppi eventi come critici comporta un aumento del costo di
gestione del rischio
 Includerne troppo pochi comporta un aumento del rischio totale


Matrice di esposizione al rischio – quantitativa
 In alcuni casi è possibile “oggettivare” gli impatti e le
probabilità in senso numerico (quando si può fare, è
senz’altro il caso di farlo)

 Ad esempio, nella valutazione dei rischi economici è
possibile usare il BAC (Budget At Completion) come valore di
riferimento

 Un evento che comporta una crescita dei costi oltre il 40%
del BAC sarebbe disastroso; tra il 20% e il 40% sarebbe
critico; ecc.


Matrice di contesto
 E’ la trasposizione del diagramma di contesto sotto forma di
tabella
1. Individuare le classi di rischio
2. Per ogni classe, individuare gli item che ne fanno parte
3. Assegnare a ciascun item una probabilità di accadimento
4. Assegnare a ciascun item un peso (ad esempio: 1 = impatto
trascurabile, 10 = impatto catastrofico)
5. Assegnare a ciascun item il suo “livello di controllo” (C, I, D)
6. Moltiplicare per ciascun item la probabilità per il peso legato
all’impatto


Matrice di contesto – esempio (1)
Classe Rischio Probabilità (p) Impatto (I)
Aspetti economici Costo materie 25% 8
prime
Tasso di cambio 30% 3
Recupero crediti 40% 2

Logistica Trasporti 10% 5
Aree di 20% 2
stoccaggio
Risorse umane Skill insufficiente 30% 7
Turnover 40% 3


Matrice di contesto – Note
 Cercare di valutare le probabilità in modo oggettivo (per
quanto possibile)
 Attenzione agli eventi tra loro non indipendenti: Andrebbero
trattati come singoli item
 I coefficienti di impatto sono “euristici”. Cercare di renderli il
più possibile “oggettivi”
 La classificazione adottata (1 – 10) è solo indicativa
 Tuttavia è importante: definisce la “scala della misura”


Matrice di contesto – esempio (2)
Classe Rischio C I D

Aspetti economici Costo materie prime 2

Tasso di cambio 0,9

Recupero crediti 0,8

Logistica Trasporti 0,5

Aree di stoccaggio 0,4

Risorse umane Skill insufficiente 2,1

Turnover 1,2


Matrice di contesto – Analisi per classe
Sommare i valori sulle classi

Classe C I D Totale
Aspetti economici 0,8 2,9 3,7

Logistica 0,5 0,4 0,9

Risorse umane 2,1 1,2 3,3

Totale 0,5 3,3 4,1


Matrice di contesto – Rappresentazione

Aspetti economici
4

3

2

1

0

Risorse umane Logistica


Coefficiente di autodeterminazione
 Indichiamo con C, I, D i totali ottenuti dalla matrice di
contesto

 Il coefficiente di autodeterminazione è espresso dalla
formula:

C I
CA 2 100
C I D


Coefficiente di autodeterminazione – Note
 Rappresenta il “grado di controllo” che abbiamo sui rischi di
progetto

 E’ un valore percentuale

 E’ sempre compreso tra 0% e 100% perché il numeratore
non può che essere minore del denominatore

 Non è tanto importante il suo valore assoluto, ma come
cambia a fronte di modifiche nella WBS


Efficacia delle contromisure
 Può essere misurata in base al coefficiente di
autodeterminazione, calcolato in assenza di contromisure
(Ante) e in presenza delle stesse (Post)

CAPost
I Eff 1 100
CAAnte


Progetti e know-how aziendale
 Il progetto è il luogo in cui si utilizza e si forma il know-how
aziendale

 Nessuno dei due aspetti è ovvio

 L’interesse nei confronti dei meccanismi di formazione e di
utilizzo del know-how è sempre stato molto alto

 A partire dalla fine degli anni ‘80 si è tentato un approccio
sistematico e almeno in parte sistemico al problema, noto
come knowledge management


Knowledge Management
 In linea di principio è la disciplina che dovrebbe portare a
gestire la conoscenza

 Termine coniato nel 1986 da Karl Wiig, attualmente CEO del
Knowledge Research Insitute

 L’interesse per questa disciplina è cresciuto fino alla fine
degli anni ‘90, per poi declinare


Due approcci (apparentemente) inconciliabili
 Approccio centralizzato:
la gestione della conoscenza è diretta dall’alto
 Dal punto di vista organizzativo
 Dal punto di vista dei contenuti
 Dal punto di vista degli strumenti
 Tipici esempi: Web semantico, Knowledge Management vecchia maniera

 Approccio distribuito:
la conoscenza emerge dal basso (bottom-up)
 Non esiste un’organizzazione
 I contenuti sono auto prodotti
 Si usano gli strumenti disponibili
 Tipici esempi: Web 2.0, sistemi di tag, blogosfera


Enterprise 2.0
 Il termine è stato introdotto da Andrew McAfee in un
celebre articolo del 2006 (Enterprise 2.0: The Dawn of
Emergent Collaboration)

 Si riferisce in generale all’utilizzo di strumenti web di tipo 2.0
nel contesto dell’attività aziendale

 Punta alla definizione di metodologie per il Knowledge
Management che siano effettivamente bottom-up

 Si declina soprattutto nei progetti


Un esempio di McAfee (1)
 Nel suo articolo McAfee cita il caso avvenuto presso una
banca d’affari tedesca, la Dresdner Kleinwort Wasserstein

 La banca aveva appena installato tre nuovi strumenti
tecnologici (software per blog, wiki e messaggistica)


Un esempio di McAfee (2)
 Qualcuno si è accorto che “mancava” un componente che
segnalasse la presenza delle persone sulla propria
postazione di lavoro, e ha suggerito una soluzione “rozza”
che permetteva di risolvere subito il problema

 Anziché attivare un (lungo) processo interno che avrebbe
portato a una nuova release di software, la semplice
segnalazione “molti a molti” ha permesso di risolvere il
problema in circa un’ora


Problemi legati all’approccio 2.0 ai progetti (1)
 Le logiche 2.0,come abbiamo detto, sono intrinsecamente di
tipo distribuito

 Tuttavia l’azienda, almeno per il momento, non sembra
disponibile a rinunciare al classico approccio centralizzato
 L’azienda si comporta come un “esercito schierato a battaglia” nella
guerra del business
 Questo atteggiamento richiede un generale in capo, dei colonnelli ecc.
 In qualche modo la visione 2.0 implica una forte responsabilizzazione
dal basso
 Questo comporta anche una polverizzazione dei momenti decisionali


 Sistemi distribuiti sono tipicamente di tipo complesso

 Questo non solo è stato fatto notare, ma è stato anche
teorizzato come aspetto positivo della rivoluzione incipiente

 Ci si aspetta che il gruppo eserciti la sua creatività culturale,
cioè che nascano idee, pratiche, metodologie di tipo
emergente

 NB: la constatazione che le finalità aziendali non coincidono
“naturalmente” con quelle di chi opera in azienda non è
nuova

 Il problema è che i sistemi complessi difficilmente sono
indirizzabili verso un fine preciso...

 La differenza principale tra un progetto complesso e un
sistema complesso è che il progetto esiste finché ne esistono
gli obiettivi

 Un sistema complesso trova i suoi obiettivi in corso d’opera
 Un esempio di Jay Gould: le ossa delle branchie dei pesci si sono
trasformate in quelle dell’orecchio interno dei vertebrati terrestri


Adottare una prospettiva 2.0 per i progetti?
 In una prospettiva di medio/lungo termine potrebbe essere
inevitabile

 Ci saranno resistenze anche perché i nuovi strumenti, che
non sono nati nel contesto aziendale, verranno visti come
“alieni” rispetto a un possibile utilizzo in azienda

 Probabilmente la nuova impostazione richiede di essere
introdotta in modo graduale

 In ogni caso non è inconciliabile con quella “centralizzata”


Caratteristiche del Project Management 2.0

Da Wikipedia


E’ collegato a diverse teorizzazioni (1)
 Agile Project Management (2001)

 Nato nel contesto dei progetti software, è stato esteso al PM
in generale

 I principi base:
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

 Suggerito soprattutto per i piccoli progetti

 Agile è uno dei (tanti) modelli che sono stati proposti per
superare i limiti del cosiddetto approccio “waterfall”


 Il modello “waterfall” è stato definito nell’ambito
dell’industria meccanica, e successivamente adottato per i
progetti software (anni ‘70)

 Il suo limite fondamentale è che nella sua formulazione base
è poco realistico

 Risulta infatti impossibile in molti casi ultimare una fase
prima di procedere con quelle successive


 Un altro limite del modello del waterfall è la sua rigidità a
fronte di possibili
 Cambiamenti dei requisiti
 Necessità di modificare le specifiche in corso d’opera
 Novità tecnologiche che potrebbero aiutare il progetto

 Un terzo limite è quello del suo evidente non parallelismo
(le fasi sono tutte dipendenti ciascuna dalla precedente!)
 Waterfall definisce “di per sé” un percorso critico


Organizzazione di un progetto 2.0 (esempio)
 Pianificazione di progetto
 Raccolta requisiti (Blog, Document sharing)
 WBS e gannt (Strumenti standard estesi all’intero gruppo di progetto)
 Risk plan
• Identificazione dei rischi (Forum esteso)
• Quantificazione dei rischi (analisi a cura del PM, contributi esterni)

 Controllo di progetto
 Avanzamento (Tracking gannt gestito direttamente dai resp. dei WP)
 Comunicazione interna al gruppo di progetto (Blog o Forum)
 Pubblicazione periodica degli stati di avanzamento (Document sharing)


Approcci collaborativi al progetto (1)
 Si è già parlato delle difficoltà culturali che questo aspetto
comporta
 Trasformare gli operatori aziendali da esecutori a responsabili del
progetto e del suo successo
 Misurare la gente sugli obiettivi e non sul tempo
 Valorizzare l’apporto di ciascuno anche al di fuori degli schemi e dei
ruoli
 Vedere il processo non come una macchina, ma come un meccanismo
regolativo sociale
 Ammettere che il gruppo di progetto “scopra” soluzioni che erano
sfuggite al management
 Accettare i rapporti gerarchici di fatto, al di là degli organigrammi


 In particolare entra in crisi il ruolo del Project Manager

 In una prospettiva “uno a molti” è l’unico che detiene il
controllo di progetto
 Questo lo rende spesso un “collo di bottiglia”
 C’è spesso una separazione tra ruolo organizzativo e ruoli tecnici: il PM
è estraneo agli aspetti tecnici del progetto

 Nella nuova visione del progetto, il PM deve imparare a
“governare” più che a “dirigere”



Blog
Posta Wiki
elettronica

Forum

Keyword
Tag

Archivi
Riunioni
documentali


Condivisione di informazioni con l’”esterno”
 Anche il cliente può diventare un soggetto attivo nello
sviluppo del progetto
 Non è detto che “debba vedere tutto”
 Può avere un accesso limitato alle informazioni

 Lo stesso si può dire per
 I partner commerciali
 I partner tecnologici
 I fornitori
 ...


Il PM 2.0 avrebbe salvato Ashton Tate?
 In azienda tutti sapevano che c’erano dei problemi

 I gruppi di sviluppo sapevano che i problemi erano legati al reverse
engeneering

 Tra coloro che operavano nei gruppi di sviluppo, molti erano consapevoli
del fatto che i problemi erano critici, e che occorreva cambiare rotta

 La catastrofe è stata determinata, almeno in parte, dallo scarso peso
decisionale dei gruppi tecnici rispetto a quelli commerciali/marketing

 In particolare dalla mancanza di strumenti di valutazione tecnica da
parte del management


Introduzione al Project Management

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (19)

Semelhante a Introduzione al Project Management

Semelhante a Introduzione al Project Management (20)

Introduzione al Project Management

Notas do Editor