introduzione al project management

Introduzione al Project Management

Concetti base e definizioni

Piero Schiavo Campo

INTRODUZIONE1

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”


LA PIANIFICAZIONE DEL PROGETTO2.

La gestione dei progetti – 1. Il Project Management

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


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)


La gestione dei progetti – 1. Il Project Management

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

meccanismi di riporto


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 DEL PROGETTO3.

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.


I RISCHI DI PROGETTO – UN ESEMPIO REALE

4.

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

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

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


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

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

Lf nN

1

11

n

nN

L

t

Livello 0

Livello 1

Livello 2

Nodi “foglia”:

Nodi totali:

Livello 0

Livello 1

Livello 2

Livello 3


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

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%

Pro

bab

ilità

di "

erro

re"

in u

n b

locc

o

Numero di blocchi


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)


LA GESTIONE DEL RISCHIO DI PROGETTO

5.

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 rischib) → 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à

Problema: le valutazioni

degli studenti e del personale sono molto

basse

Ambiente

MenùPersonale

Manca un cuoco di livello

Poco motivato

Piatti presentati male

Materie prime scadenti

Sottodimensionato

Scarsa pulizia

Saloni “vecchi”

Scontroso

Sottodimensionato


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

0

10

20

30

40

50

60

70

Ritardo nellaconsegna

Consegnatiprodotti sbagliati

Consegnatiprodotti difettosi

Fatturazioneerrata

Consegna nonavvenuta

Cause dei reclami

Nu

mer

o d

ei r

ecla

mi

0,00%

10,00%

20,00%

30,00%

40,00%

50,00%

60,00%

70,00%

80,00%

90,00%

100,00%

% d

ei r

ecla

mi

Numero reclami

% cumulata


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

Info

rtu

nio

Fu

rto

Ince

nd

io

Gu

asto

Van

dal

ism

o

Alla

gam

ento

Personale Cabina elettrica Magazzino

Container Ricambi

MezziMovimentazione Sollevamento


Diagramma di contesto

Area/Tipo 1

Area/

Tipo 2Area/Tipo 3

Area/

Tipo 4

S

F

S

S

S

F

F

F

F

F

F

S

Fattori

Soggetti

Dipendenza

Influenza

Controllo


Bournett e Youker 1980, Archibald 2000

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)


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

Mol

to a

lta

Alta

Med

ia

Bas

sa

Mol

to b

assa

Catastrofico

Critico

Consistente

Marginale

Trascurabile

Probabilità

Imp

atto

D

E

BC

A

GF

H

Eventi


Livelli di esposizione al rischio

Mol

to a

lta

Alta

Med

ia

Bas

sa

Mol

to b

assa

Catastrofico

Critico

Consistente

Marginale

Trascurabile

ElevatoIntensoLimitatoModesto

Probabilità

Imp

atto


Soglia di attenzione

Mol

to a

lta

Alta

Med

ia

Bas

sa

Mol

to b

assa

Catastrofico

Critico

Consistente

Marginale

Trascurabile

Probabilità

Imp

atto


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 tabella1. Individuare le classi di rischio2. Per ogni classe, individuare gli item che ne fanno parte3. Assegnare a ciascun item una probabilità di accadimento4. 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 prime

25% 8

Tasso di cambio 30% 3

Recupero crediti 40% 2

Logistica Trasporti 10% 5

Aree di stoccaggio

20% 2

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 classeSommare 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

0

1

2

3

4Aspetti economici

LogisticaRisorse umane



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

contesto

Il coefficiente di autodeterminazione è espresso dalla formula:

1002

DIC

ICCA


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)

1001

Ante

PostEff CA

CAI


IL PROJECT MANAGEMENT 2.06.

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


E’ collegato a diverse teorizzazioni (2) 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”



Posta elettronica

Forum

Riunioni

BlogWiki

Tag

Archivi documentali

Keyword


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

Business