Il progetto è un processo in cui risorse umane, materiali e finanziarie sono organizzate in modo nuovo per
realizzare un output unico all'interno di vincoli definiti di tempo e di costo. Elementi che caratterizzano un
progetto rispetto a un processo:
1) L'Unicità Dell'Output  l'oggetto che deve essere realizzato è significativamente differente da ciò che è
stato fatto in precedenza. Tale unicità comporta quindi un grado più o meno elevato di novità nell'output
realizzato: può essere un prodotto completamente nuovo; oppure mostrare alcuni elementi di unicità, può
essere nuovo per l'impresa. Ne consegue che non è possibile definire modelli standard ma è necessario
comprendere i fattori contingenti che rendono critici diversi aspetti del progetto.
2) Unicità Della Realizzazione  anche la modalità di realizzazione del progetto presenta elementi di novità
rispetto a quanto l'impresa svolge normalmente e quindi ogni progetto richiede di fatto un flusso di attività
che va identificato e messo a punto ad hoc. E’ necessario definire un'opportuna struttura organizzativa per
la sua gestione, in quanto è necessario che le risorse vengano impiegate in modo differente da come sono
utilizzate per la gestione dell'attività correnti (può essere richiesto il coinvolgimento di risorse che sono
effettivamente nuove per l'impresa).
3) Temporaneità  i progetti hanno una vita la cui durata è definita da quando l'output deve essere reso
disponibile; questo aspetto richiede anche di progettare un sistema organizzativo in grado di esistere per
un periodo limitato; può essere richiesta la costruzione di un'organizzazione non esistente con nuovi
addetti oppure nel caso opposto (organizzazione già esistente) si rende necessario specificare modalità di
coordinamento e interazione delle unità esistenti.
4) Riduzione Dell'Incertezza  raramente all'inizio di un progetto è completamente chiaro cosa il progetto
va a realizzare e come. La definizione degli obiettivi e la loro traduzione in attività è una operazione
raramente lineare, ma si basa su un'elaborazione progressiva, in cui, attraverso approssimazioni successive
e grazie alle informazioni generate nel corso della elaborazione stessa, si va a chiarire e dettagliare cosa il
progetto realizza e come.
5) Competenze  spesso nei progetti è necessario utilizzare competenze nuove, mai adottate in
precedenza. Può anche capitare che sia necessario sviluppare nuova conoscenza direttamente durante il
progetto stesso.
6) Finalizzazione  è necessario dedicare tempo e risorse alla definizione di cosa il progetto debba
realizzare prima di poterlo avviare, anche al fine di poter valutare la qualità dell'output generato.
Tipologie Di Progetti
1) Progetti Su Commessa  sono compresi tutti i progetti per i quali un cliente richiede esplicitamente un
determinato output con ben definite caratteristiche; caratteristica comune di questa tipologia di progetti è
la presenza di un cliente ben definito con cui viene solitamente redatto un contratto.
2) Progetti A Catalogo  sono i progetti in cui non vi è un determinato cliente che esplicitamente richiede
la realizzazione di un progetto, ma un cliente potenziale (o target) che il progetto mira a soddisfare.
Fasi Di Un Progetto
1) Initiating  la fase della nascita, in cui, identificato un problema da risolvere o una opportunità da
cogliere, si valuta la fattibilità tecnica, economica, strategica di svolgere un progetto. Questa fase mia
quindi a decidere se eseguire un progetto e, in caso, definire cosa esso debba realizzare. L'input può essere
molto diverso da progetto a progetto (acquisizione contratto da parte di un cliente, acquisizione particolare
tecnologia, ecc). Questa fase termine tipicamente con la definizione degli obiettivi specifici (scope, tempi e
costi di realizzazione) e con l'autorizzazione formale a procedere.
2) Planning  fase in cui si definisce e si pianifica il progetto, definendone lo scope. Questa fase culmina
nella stesura del piano di progetto cioè il documento che fa da riferimento per tutte le attività di
realizzazione.
3) Executing & Controlling  è la fase in cui effettivamente viene realizzato l'output, dove si effettuano gli
investimenti si controlla le attività svolte per verificarne l'aderenza al piano. Inoltre durante questa fase
viene anche la revisione dà pianificazione stessa laddove il progetto subisca nel tempo delle modifiche.
4) Chiusura  era fasi in cui l'output del progetto viene rilasciato per il funzionamento regime si verifica il
grado di raggiungimento degli obiettivi.
Project Management  è l'insieme dei principi, logiche e metodi generali per la gestione di progetto. La
gestione di progetto è costituito innanzitutto dalla filosofia di gestione; e inoltre un'impostazione
organizzativa riguardante la gestione delle risorse dell'attività e da ultimo è un insieme di strumenti che
permettono di pianificare, controllare e organizzare le attività che costituiscono un progetto.
Le principali fasi in cui si compone un progetto sono: inizializzazione, pianificazione, esecuzione e controllo,
la chiusura. Ogni fase riceve alcun input da altre fasi in genere output necessari per le altre fasi. Queste fasi
non sono sempre perfettamente sequenziali, ma possono essere logicamente e temporalmente
sovrapposte. La sequenza e la sovrapposizione è legata alla diversa natura dei progetti descritti ma anche
diverse modalità con cui le imprese decidono di gestirli. Ciò che spesso rende necessario sovrapporre
differenti fasi e che esse generano informazioni necessarie per far sì che logicamente vengono prima. Le
fasi fondamentali in questo articolo un progetto sono spesso complesse, multidisciplinari, sovrapposte
interconnesse tramite generazione di output intermedi.
1) Inizializzazione  ha un output fondamentale la decisione se procedere o meno con lo svolgimento del
progetto. I progetti che prevedono gare di aggiudicazione si parla di decisioni di Bid/No Bid per sottolineare
come, in ambienti molto strutturati come il più delle volte le offerte costituiscono impegni vincolanti, le
imprese lavorino per decidere se partecipare alla gara (bid). È opportuno sottolineare come la decisione di
partecipare non costituisca di per sé la partenza del progetto. La gara potrebbe infatti anche essere persa, o
potrebbe aprirsi una fase di negoziazione che potrebbe modificare il progetto stesso al punto da rimettere
in discussione la decisione di Bid. In questi casi l'output finale di questa fase è, nel caso di assegnazione del
lavoro, la firma del contratto mentre, nel caso di non assegnazione, l'archiviazione dell'offerta. Le attività
fondamentali di questo processo riguardano le analisi relative alla fattibilità tecnica ed economica del
progetto e alle valutazioni dell'opportunità strategiche, tecnologiche e di mercato. Il processo di
pianificazione strategica (che, definendo le priorità strategiche, individui rapporti di precedenza tre
progetti) è seguito dal processo di pianificazione economica e finanziaria (l'individuazione vincoli al
portafoglio dei progetti) infine dal processo di definizione della strategia tecnologica (identificazione
tecnologie future). È possibile distinguere tra parti fondamentali di questa fase:
A) Generazione Statement of Work  è la richiesta di progetto e contiene le informazioni relative alla
necessità che devono essere soddisfatte, il tipo di output, le richieste del mercato, le innovazioni di
processo, le necessità di rispettare i nuovi standard imposti da nuove leggi,ecc. tale descrizione è però
solitamente non molto dettagliata poiché contiene per esempio i requisiti funzionali del prodotto, i requisiti
prestazionali ma non le specifiche di dettaglio dell'output. Praticamente tale documento descrive cosa
dovrà fare l'output del progetto ma non come. Nel caso di progetti su commessa è costituito da un
documento formale di richiesta da parte del cliente; solitamente tale documento è creato da un membro
interno o esterno dell'azienda. Nel caso di membro esterno in esso farà pervenire all'impresa una richiesta
specifica che potrà essere, a seconda dei casi una RFI (Request for Information cioè una richiesta su come
potrebbe essere soddisfatto un bisogno partire dalle conoscenza dell'impresa) oppure una RFP (Request for
Proposal cioè la richiesta di un'offerta formale per la progettazione e realizzazione di un output) oppure
una RFQ (Request for Quotation cioè la richiesta di una quotazione per un prodotto di cui è stato già
definito un progetto di alto livello).
B) Generazione Project Charter  le informazioni contenute nel SOW non sono sufficienti per alimentare il
processo decisionale e quindi tale documento deve essere tradotto in un Project Charter cioè un
documento più completo poiché contiene informazioni dettagliate aggiuntive. Lo scopo del PC piccolo di
fornire un insieme di informazioni sufficienti per decidere se procedere o meno con lo svolgimento del
progetto. Informazioni contenute:
a) Motivazioni Alla Base Del Progetto  questa sezione è corredata da un documento che mostra sia gli
impatti attesi dal l'output del progetto sia gli impatti della sua non realizzazione.
b) Obiettivi Specifici Di Progetto  e necessario identificare gli obiettivi di dettaglio cioè specifiche del
prodotto stesso (tutte le sue funzioni prestazioni), del processo di produzione, il tempo entro cui il prodotto
deve essere lanciato sul mercato e dal costo di produzione. La definizione degli obiettivi specifici sarà
influenzata dalla strategia aziendale cioè dai suoi obiettivi strategici. Esistono stretti legami tra ogni singolo
progetto gli obiettivi strategici aziendali, nel senso che al progetto è richiesto un determinato contributo
per la realizzazione di tali obiettivi. Il singolo progetto nascerà quindi per soddisfare obiettivi strategici ma,
per poterlo svolgere, e si dovranno essere tradotti in obiettivi specifici. Il responsabile del raggiungimento
degli obiettivi specifici di progetto e l'project manager ma sarà la committenza (cioè chi ha la responsabilità
del budget su cui graverà il progetto) a definire gli obiettivi strategici; inoltre la committenza il compito di
definire quali progetti entreranno nel portafoglio aziendale e cosa dovranno produrre come output
specifico. La committenza presidia dunque anche la relazione tra obiettivi strategici aziendali e obiettivi
specifici di progetto. È possibile che più progetti agiscono contemporaneamente per realizzare uno stesso
obiettivo strategico; per questo motivo non è sensato misurare come performance dei progetti
raggiungimento degli obiettivi strategici ma bensì va misurata la loro capacità di raggiungere gli obiettivi
specifici. In questa sede vengono anche definiti i principali deliverable di progetto, ossia ogni forma di
output, si intermedio che definitivo, che fluisce dal progetto verso il cliente, esterno all'interno
(documentazione di progetto, prototipi, documenti progettuali,ecc).
c) Macro Attività E Organizzazione  è opportuno definire quali saranno le macro attività da svolgere e
quali risorse organizzative saranno coinvolte. Vengono effettuate anche le stime di fattibilità tecnica e si
analizza la reale capacità dell'impresa di svolgere le attività di progetto; si esegue inoltre una pre-analisi per
decidere se e quali attività saranno svolte interamente all'interno dell'azienda o delegate esternamente
(decisioni di “make or buy”).
d) Tempi E Costi
e) Rischi
Il PC comprende quindi indicazioni strategiche, tecniche, di tempo, di costo, di rischio ecc; a qui mi una
natura fortemente multidisciplinare. Dal punto di vista organizzativo, la sua elaborazione richiedente
reazioni diverse competenze aziendali (funzioni tecniche, funzioni amministrative, funzioni finanziarie,
legali, esperti in materia,ecc). Ne consegue che è necessario curare il coordinamento di tale fase e ciò viene
portato a termine da uno specifico ruolo denominato Proposal Manager.
C) Approvazione Del Progetto  è necessario realizzare una valutazione di carattere economico-finanziario
che fa riferimento allo schema tipico di analisi degli investimenti. Il costo complessivo legato all'utilizzo
delle risorse può essere calcolato in modo simile per tutte le tipologie di progetto presentate. I progetti
invece si differenzia per quanto riguarda il calcolo dei ricavi; nel caso di progetti su commessa all'analisi
semplice in quanto viene stabilito a priori tra le parti il controvalore monetario che il cliente riconosce così
come il piano di pagamenti in relazione al avanzamento del progetto. Per le altre tipologie di progetti
invece la definizione dei ricavi comporta maggiori difficoltà; nel caso di progetti a catalogo vi è la necessità
per l'azienda di stimare alcuni parametri fondamentali quali le unità vendute, il prezzo di vendita e la durata
del ciclo di vita del prodotto. La necessità di effettuare tale stime rende più complessa ed aleatoria l'analisi
economiche finanziarie del progetto, aumentando il livello di rischio. Anche la valutazione economica
finanziaria di un progetto va integrata con valutazioni strategiche più ampia (esempio incominciare a
lavorare con un cliente di riferimento del settore, possibili effetti sull'immagine dell'impresa, progetti
tecnologici).
D) Lancio Del Progetto  il decisore ultimo del processo di inizializzazione è la committenza. Al fine di
ottenere la massima integrazione tra i processi è considerata buona pratica coinvolgere il project manager
fin dal processo di inizializzazione, come garante delle stime di tempo di costo che saranno fatte, essendo
poi lui la persona che dovrà risponderne. Il PM sarà solo una delle risorse coinvolte presterà al processo le
proprie competenze ove necessario. Colui che coordinerà l'intero processo sarà il Proposal Manager.
2) Pianificazione, Esecuzione E Controllo  il processo di pianificazione ha come output finale la creazione
del piano di progetto (project management plan), che copre tutti gli aspetti del progetto: scope, tempi,
costi, risorse umane, organizzazione, rischi, qualità, comunicazione e acquisti. Il piano di progetto è
l'evoluzione del project charter, sia per quantità di aspetti trattati che per la profondità il dettaglio della
loro analisi. Per le successive pianificazioni, durante l'esecuzione progetto, l'imput sarà la versione
precedente il piano di progetto, unitamente ai risultati dei controlli sull'avanzamento il piano stesso. Tali
risultati sono dunque l'output fondamentale del processo di controllo che alimentato non solo dalla
versione aggiornata del piano di progetto ma anche, e soprattutto, dei risultati dei controlli di avanzamento
svolti sulle attività.
Decentramento  Il project manager, essendo responsabile del raggiungimento degli obiettivi specifici di
progetto, dovrebbe pianificare controllare tutti gli aspetti nei minimi dettagli; nei casi di progetti di grosse
dimensioni ciò è impossibile ed è necessario ricorrere al decentramento decisionale. Il team di progetto
sarà in grado di definire nel dettaglio il lavoro da svolgere e di pianificare i tempi e le risorse necessarie. Il
compito del PM sarà quello della messa a fattor comune delle pianificazione di dettaglio, controllandone la
coerenza in termini di tempi, di costi e di contenuto. Anche per quanto riguarda il controllo
dell'avanzamento di progetto il discorso analogo; solo che svolge realmente l'attività in grado di definirne
con cognizione di causa quale sia il suo avanzamento. Ancora una volta, il project manager avrà il compito
di mettere sotto il cumulo tutte le informazioni di controllo distribuito e di ricavarne una visione unitaria.
Nel caso il controllo avrà necessario un secondo livello di attenzione. Soprattutto sui progetti di grosse
dimensioni, la quantità di dati di controllo potrebbe essere ingente e il loro processamento in modo
centralizzato da parte del project manager potrebbe richiedere molto tempo, trasformandosi rapidamente
in un collo di bottiglia. Per tale motivo opportuno che il controllo a livello centrale sia filtrato attraverso il
concetto di "allarme". Nel momento in cui avverrà un disallineamento tra pianificazione attività correnti,
pare d'avere impatti su altre sotto parti del progetto, bisognerà allarmare il PM che valuterà gli impatti
sistemici del disallineamento vaglierà le possibili contromisure.
Livello di dettaglio  non tutti progetti vengono pianificati controllati con lo stesso livello di dettagli e
addirittura anche all'interno di un singolo progetto alcuna attività potrebbero essere pianificate e
controllate con livelli di dettaglio distinti. Fattori che incidono: A) L'Esperienza Dei Componenti Del Team Di
Progetto  per team di progetto particolarmente esperti può risultare non indispensabile scomporre al
massimo dettaglio le attività di progetto, in quanto attività anche aggregate saranno comunque facilmente
identificabile controllabili grazie all'esperienza. B) Politiche di Outsourcing  nel caso di attività affidate in
outsourcing a fornitori, potrebbero essere necessaria dettagliare le attività richieste per realizzare un certo
compito. Può essere comunque importante definire delle scadenze intermedie per evitare perdite di
controllo delle attività esternalizzate. C) Rolling Wave  descrive con il massimo dettaglio attività di un
progetto che saranno svolte a grande distanza di tempo è difficile e inutile. Utilizzando la logica di RW è
possibile eseguire un'elaborazione progressiva della pianificazione, nella quale il lavoro da svolgere nel
prossimo futuro programmati in dettaglio, mentre il lavoro da svolgere in futuro più remote pianificato in
maniera più aggregata.
Controllo in Feed-Forward e Feed-Back  il modificarsi di variabili interne ed esterne impatti era sul
progetto discostando dalla pianificazione eseguita. Il controllo diventa quindi cruciale, al fine di
implementare tempestivamente le azioni correttive necessarie per raggiungere gli obiettivi. Esistono due
approcci distinti:
A) FB  si basa sull'osservazione di quanto accaduto realmente durante il progetto, sul confronto tra
quanto osservato e ciò che la pianificato e sull'analisi delle cause e gli eventuali spostamenti al fine di
definire gli interventi correttivi.
B) FF  si cercano di anticipare gli effetti che le variabili interne ed esterne potrebbero avere sui risultati
finali, quando il progetto è ancora in corso. L'osservazione continua delle variabili interne ed esterne del
progetto, permette la previsione del loro andamento nel tempo e la stima del loro impatto futuro sul
progetto.
Per è un efficace controllo è necessario combinare i due cicli; infatti, per ripianificare opportunamente
progetto, è necessario integrare le informazioni derivanti dal FB con quelle del FF , in modo da identificare
interventi correttivi che, da una parte, siano basati sui risultati finora ottenuti e sullo stato di avanzamento
del progetto e, dall'altra, tengano conto di quanto anticipato in termini di evoluzione delle variabili esterne
e interne. Anche le attività di controllo devono essere pianificate (cosa viene controllato, con che frequenza
e da chi)
EVM  Earned Value Management; è un metodo di controllo molto efficace per il controllo integrato di
tempi e costi; fornisce indicazioni puntuali sullo stato di avanzamento del progetto, indicazioni previsionali
sul futuro andamento del tempo dei costi di progetto e permette di simulare i piani di recupero è di
esprimere un giudizio sulla loro reale fattibilità. Non viene in nessun modo analizzata la qualità del lavoro
già eseguito.
BCWS  Budgeted Cost Work Scheduled; rappresenta l'andamento dei costi cumulati di progetto per ogni
intervallo di tempo. La BCWS di progetto sarà determinata dalle aggregazioni delle BCWS dei differenti
control account. Normalmente assume una forma ad S dovuto al fatto che solitamente nelle prime fasi di
progetto di una spesa ridotta; successivamente tale curva cresce più velocemente in corrispondenza della
fase di esecuzione, nella quale si sostengono i maggiori costi. La curva infine rallenta la propria crescita
quando ci si avvicina alla fase di chiusura. Non esisterà mai una BCWS discendente poiché essa è la
sommatoria dei costi dei mesi precedenti; al massimo, se non vengono effettuate spese, sarà costante cioè
con derivata nulla. La costruzione prevede l'incrocio dei dati della pianificazione temporale con quella dei
costi.
ACWP  Actual Cost Work Performed; grazie alla contabilità aziendale è possibile ricavare questo
parametro che indica quanto si sia in realtà speso per il control account fino a un certo istante. Fino al
termine del control account non è possibile confrontare il preventivo con il consuntivo e non è possibile
capire quale sia la causa dello scostamento. La differenza tra preventivo e consuntivo dipende da due
incognite distinte: A) efficienza/inefficienza (esborso maggiore/minore rispetto al preventivo) B)
anticipo/ritardo.
BCWP  Budget Cost Work Performed; esprime l'avanzamento fisico dell'attività del control account
valorizzato a costi di budget. Confrontando questa curva con ognuna delle altre due è possibile
comprendere il reale andamento del control account.
BCWP < BCWS  il control account è in ritardo
BCWP > BCWS  il Control Account è in anticipo
BCWP < ACWP  il control account è inefficiente
BCWP > ACWP  del Control Account è efficiente
Indicatori Relativi [calcolati in %]
CPI  Cost Performance Index
CPI = BCWP / ACWP se maggiore di uno indica efficienza
SPI  Schedule Performance Index
SPI = BCWP / BCWS se maggiore di uno indica anticipo
L'analisi dell’andamento del progetto non può basarsi solo sugli indicatori relativi in quanto essi descrivono
l'andamento delle performance solo in termini percentuali rispetto alla pianificazione e quindi non
permettono di valutare la reale portata economica di tali performance; per questo sono basilari gli
indicatori assoluti.
Indicatori Assoluti [calcolati in unità monetarie]
CV  Cost Variance
CV = BCWP – ACWP se maggiore di zero indica efficienza
SV  Schedule Variance
SV = BCWP – BCWS se maggiore di zero indica anticipo
Earned Schedule  rappresenta l'istante a budget in cui si sarebbe dovuto raggiungere il lavoro attuale in
termini di costi.
Indicatori particolarmente positivi o negativi, non permetteranno di definire se l'errore sia effettivamente
nell'esecuzione del progetto o nella sua pianificazione che potrebbe essere stata eccessivamente
conservativa o ottimistica; l'errore di pianificazione ha impatti negativi sulle performance aziendali in
quanto non permette a quest'ultima di utilizzare le risorse in eccedenza per altri progetti.
Time Report  è uno strumento che rileva in modo puntuale frequenza fissa (settimanale o mensile) come
stato speso il tempo di ogni risorsa (cioè su quali control account e su quali progetti).
Per calcolare la curva BCWP è necessario rilevare un parametro critico da misurare cioè la percentuale di
completamento (o POC) dell'attività. BCWP = POC * BAC (Budget at Completion cioè la stima complessiva
del Control Account). La misurazione del POC può risultare in alcuni casi semplice (esempio di un'attività
che comporta un output fisico e misurabile) mentre in altri casi può essere molto complessa e poco
oggettiva (esempio avanzamento attività di pianificazione). Esistono 7 differenti metodi per il calcolo del
POC:
Metodi Discreti (cioè Oggettivi)
A) Milestone: all'interno del progetto vengono determinate un numero variabile di Milestone e ad ognuna
di essa viene attribuito un peso percentuale; al raggiungimento della milestone la percentuale di
completamento verrà incrementato del peso della milestone stessa. Il peso della milestone dovrebbe
combaciare con la quantità di risorse utilizzate sul totale. È uno dei metodi oggettivi e l'errore avviene solo
per difetto poiché i risultati intermedi non vengono contemplati.
B) 50/50: vengono posizionate solamente due milestone ognuna di peso specifico del 50%; di solito una
posta a metà del lavoro e l'altra al suo completamento. L'errore avviene sia per difetto che per eccesso.
C) 0/100 : viene posizionata un'unica milestone al termine dell'attività con peso specifico pare il 100%
D) Unità Completate: questo metodo si applica ad attività che prevedono un certo numero di output uguali;
l'avanzamento sarà qualcosa tramite rapporto fra l'unità prodotte e quelle totali. Il calcolo non tiene conto
delle curve di apprendimento della produzione.
Metodi Soggettivi
A) Percentuale Di Completamento: la percentuale di avanzamento è in questo caso stimata dal responsabile
del Control Account che si basa sulla propria esperienza e sulla conoscenza del lavoro da svolgere. È
semplice e a basso costo.
B) Sforzo Proporzionale: viene stimata la percentuale di completamento dell'attività associandola alla
percentuale di avanzamento di un'altra attività a cui la prima è logicamente collegata (esempio controllo
della produzione legata all'avanzamento della produzione stessa)
C) Level of Effort: si prevede che l'avanzamento sia proporzionale al tempo trascorso (BCWP= BCWS); viene
imposto un SPI sempre uguale a 1. È pertanto altamente sconsigliata poiché vengono comparate l'ACWP e il
BCWS praticamente il consultivo e il preventivo.
Dato che i metodi soggettivi dovrebbero essere utilizzate il meno possibile, molte imprese definiscono
vincoli formali al loro utilizzo fissando un tetto al valore massimo delle attività controllate con tali metodi.
Tuttavia l'applicabilità di un dato metodo dipende dalla natura dell'attività stessa. Ad esempio un metodo
ad unità completate si adatta ad attività di produzione, ma non ad attività di gestione che non prevedono
un output fisico. Inoltre nel caso dei metodi a milestone la scelta si basa sulla relazione fra durata
dell'attività frequenza del controllo; e in generale falso che un numero maggiore di milestone corrisponda a
un maggior controllo. È evidente che aumentando il numero di milestone si ridurrebbe la discrepanza tra il
completamento reale il completamento misurato; è però altrettanto vero che aumentare la granularità del
controllo comporta maggiori costi e maggior tempo dedicato. La scelta del metodo di misurazione degli
avanzamenti da utilizzare per ogni WP prevede la gestione di un trade-off tra precisione del controllo e
costo ad esso correlato.
Il controllo dell'avanzamento delle attività appaltate a fornitori esterni viene svolto dal PM. Nel caso di
contratti Fixed Price (in cui il prezzo delle forniture è definito a priori del fisso a meno di cambiamenti di
scope) il fornitore non è tenuto all'evidenza della propria struttura dei costi; per tale motivo, anche se si è
in grado di identificare eventuali ritardi, non è possibile identificare eventuali inefficienze. Ciò significa che il
CPI di tali attività sarà sempre pari a 1;
Calcolo della Stima al completamento (EAC  Estimate at Completion)
dopo avere calcolato gli indicatori sintetici delle performance si procede a elaborare le nuove stime di
tempo di costo per il WBE stesso. Prima di valutare eventuali azioni correttive deve essere chiaro quale
sarebbe l'andamento nel caso in cui progetto continuasse senza alcun intervento correttivo; solo in questo
modo sarà possibile effettuare un'analisi differenziale per capire se e quali interventi andranno
implementati. Per il calcolo del EAC è necessario determinare la natura delle cause che hanno portato agli
scostamenti rispetto alla pianificazione;
1) Cause Contingenti: cause che hanno influito sul WBE ma che si suppone abbiano esaurito il proprio
impatto (esempio vertenza sindacale conclusa).
2) Cause Strutturali: cause che hanno influito sul WBE e continueranno impacchettarlo anche in futuro
(esempio tensione sul mercato delle materie prime dovuta una guerra). La scelta delle cause strutturali non
risulta essere più conservativa ma bensì tende a propagare l'errore (sia positivo che negativo).
I due casi i meccanismi per il calcolo del EAC saranno differenti:
1) Cause Contingenti  EAC (€) = BAC – CV = BAC – (BCWP – ACWP)
EAC (t) = durata – SV (t) = durata – (BCWP (t) – BCWS (t))
2) Cause Strutturali 
EAC(€) = ACWP + ETC
Per calcolare l’ETC (cioè Estimate to Complete) si suppone che le performance mantenute fino al time
now (CPI e SPI) si mantengano identiche fino alla fine del WBE. L’ETC, dato dalla differenza tra BAC e
BCWP, indica il lavoro rimanente valorizzato a costi preventivi, ma siccome abbiamo supposto che
l'efficienza futura sarà uguale a quella passata dobbiamo scontare tale effetto
ETC (€) = (BAC – BCWP) / CPI
ETC (t) = time now + (durata – tempo mancante) / SPI
Le stime differiscono molto tra il caso di errore contingente quello di errore strutturale. A parità di indici di
prestazione, la supposizione di errore strutturale amplifica (sia in positivo che negativo) gli effetti sulle
stime e tale effetto si riduce con l'avanzamento delle attività. Questo effetto deve essere prese attenta
considerazione soprattutto durante le fasi iniziali dell'attività da svolgere; in tali periodi, piccoli scostamenti
di CPI ed SPI possono comportare elevate variazioni di stime, anche di ordini di grandezza, sul tempo e sul
costo del WBE che spesso sono irrealistiche. Per evitare tale distorsione è buona norma quindi porre dei
limiti alla variazioni di stima (solitamente + o – 10%) fintanto che l'attività non sia stabilizzata cioè si è
raggiunto il 20% del POC (cioè BCWP = 20% BAC). È opportuno sottolineare inoltre che la stima delle EAC è
stata effettuata supponendo che le performance di costo (CPI) e di tempo (SPI) si mantenessero uguali a
quelle misurate nell'istante di controllo (time now); si tratta in realtà di un'ipotesi semplificatrice in quanto
tali parametri possono subire modifiche dal time now in poi.
Valutazione piani di recupero
Si tratta di tecniche di valutazione dell'effettiva fattibilità di un piano di recupero proposto. Stante la
situazione attuale è possibile calcolare quali dovrebbero essere le performance, da qui in avanti, per
rispettare le nuove stime di costo e tempo espresse dal responsabile del WBE e dal suo team. Si
considerano le nuove stime di durate di costo come valori noti e si calcola quali performance di tempo (SPI)
e di costo (CPI) dovrebbero essere mantenute d'ora in avanti per rispettarle.
TCPI (to Complete CPI) = (BAC – BCWP) / (New Cost – ACWP)
TSPI (to Complete SPI) = (Durata – Tempo mancante) / (New Time – Time Now)
New Cost e New Time  nuove stime effettuate dal responsabile del WBE
Una ricerca del DOD americano mostra che una volta che il progetto è oltre il 20% del suo completamento,
gli indicatori CPI ed SPI non possano essere incrementati più del 10% alla fine del progetto. Stime
inverosimili potrebbero essere causate dalle approssimazioni usate per calcolare la percentuale di
completamento delle attività e quindi la BCWP (ad esempio potremmo essere in prossimità di una
milestone non ancora raggiunta). Ciò rende ancora più evidente come la scelta del metodo di controllo di
avanzamento di un WP che viene presa in fase di planning sia essenziale per la corretta gestione dei
progetti. Il metodo di controllo viene deciso da chi gestisce il progetto e non dal PM poiché è il primo a
conoscere al avanzamento del lavoro ai costi da caricare.
GESTIONE DEL RISCHIO (CIOÈ DELL'INCERTEZZA)
Rischio  evento incerto che se accade ha un significativo effetto (positivo o negativo) sul raggiungimento
degli obiettivi di progetto.
PARAMETRI DEL RISCHIO: 1)impatto/opportunità
2)probabilità di accadimento
Il rischio è una caratteristica intrinseca del progetto a causa del carattere di un'unicità; ciò implica un
aumento della rischiosità associata alla sua realizzazione.
AREE DI IMPATTO: 1) le attività del progetto: ad esempio l’incertezza relativa alla sperimentazione in
quanto al momento dell'attivazione del progetto è difficile prevedere i risultati della simulazione.
2) gli attori coinvolti nel progetto:ad esempio il rischio legato al fatto che un fornitore che deve eseguire dei
compiti non abbia le adeguate competenze tecniche.
3) Output: rischi che si potrebbero manifestare durante il ciclo di vita dell'output (utilizzo da parte degli
utenti).
TIPI DI RISCHIO: 1) rischi certi: non sono rischi ma problemi o opportunità che è necessario affrontare;
2) rischi conosciuti: rischi di cui si è consapevoli che potrebbero tradursi in problemi;
3) rischi non conosciuti: cioè dei quali a priori non si conosce neppure l'esistenza.
La gestione del rischio si occuperà dei rischi conosciuti.
FASI GESTIONE RISCHIO:
1) Identificazione del rischio: identificazione dei rischi principali mediante il coinvolgimento dei principali
attori e tramite l'ausilio di opportuni metodi e strumenti. Da eseguire iterativamente lungo la vita del
progetto.
Strumenti: A) checklist: l'identificazione di rischio viene per aree di competenza (Risk Breakdown
Structure). La suddivisione per aree permette di intraprendere azioni di mitigazione diversa per ogni area;
domande a cui rispondere Si/No B) archivi storici C) diagrammi causa/effetto: sono rappresentazioni
grafiche spine di pesce nelle quali vengono identificate tutte le cause, divise per aree di competenza, che
portano ad un determinato effetto D)Brainstorming: meeting composti da 6/10 persone che analizzano il
problema da punti di vista diversi poiché fanno parte di ambiti aziendali diversi; tutti hanno lo stesso
valore. E) SWOT Analysis : elenco dei punti di forza, debolezze, opportunità e minacce del progetto; stesso
numero per ogni elenco al fine di espandere l'analisi senza tralasciare nulla. Risk Register  documento in
cui vengono riportati e caratterizzati i rischi individuati; è in continua evoluzione.
2) Valutazione del rischio: l'analisi identificativa al fine di valutarne possibili impatti e la probabilità di
accadimento. Fase strumentale alla definizione della scala di priorità dei rischi di progetto, la valutazione
dell'azione di risposta e alla definizione delle contingency. Tutto ciò permette l’arricchimento del risk
register con dati di dettaglio sui singoli rischi.
Tipi di analisi: A) analisi qualitativa  determinazione dei rischi più critici e attribuzione di una valutazione
di tipo alto, medio, basso o su scala numerica. La valutazione si riferisce sia la probabilità che esso si
verifichi, sia al suo impatto in termini di tempi costi e prestazioni. Tale analisi permette di determinare la
matrice di probabilità/rischio che riporta nelle celle i fattori di rischio cioè il prodotto della probabilità per
l'impatto del rischio. Esso consente di definire la priorità dei rischi attraverso una classifica in ordine
crescente in base al rischio calcolato. B) analisi quantitativa viene eseguita sui rischi più importanti
determinati dall'analisi qualitativa attraverso stime numeriche della probabilità di ogni rischio e del suo
impatto atteso (espresso in termini di extra costi, ora giunge di lavoro, tempi). Impatto atteso =
probabilità[%]*impatto[€]. Probabilmente il ranking stilato precedentemente varierà.
3) Pianificazione delle azioni di risposta: viene eseguita poiché è necessario stabilire mediante quali azioni si
intendono affrontare i singoli rischi/opportunità di progetto. L'attività deve essere supportata da un'analisi
delle cause scatenanti dei singoli rischi e deve mirare alla diminuzione dell'impatto e/o probabilità di
accadimento del rischio. Solitamente ci si concentra sul parametro che permette di migliorare di più le
performance cioè verranno eseguite quelle operazioni con il costo minore ma che ridurranno
maggiormente il rischio. Minor impatto  Protezione (es. Airbag) Minor probabilità  prevenzione (es.
ABS).
Strategie di risposta al rischio: A) Avoid: modificare il piano di progetto al fine di eliminare la minaccia
oppure rendendo gli impatti del rischio non più rilevanti. B) Transfer: spostare il rischio verso una terza
parte in modo da lasciare la responsabilità della gestione del rischio quest'ultima rendendo così di fatto il
progetto insensibile all'occorrenza di un rischio. (es. contratti che bilanciano il rischio tra cliente fornitore
oppure assicurazioni sul rischio). C) Mitigate: ridurre la probabilità che un rischio si presenti o ridurre il suo
impatto attraverso azioni specifiche che comportano un costo certo. L'azioni di mitigazione diventa parte
integrante dal progetto quindi va aggiunta alla WBS con l'allocazione di costi e tempi. D) Crisis Managment :
non viene effettuata alcuna azione preventiva e viene deciso di intervenire solo nel caso in cui il rischio
effettivamente accada.
Le quattro strategie si differenziano tra loro nella gestione del trade-off tra costi certi iniziali (per la messa
in atto dell'azione di risposta) e i costi probabili in caso di accadimento del rischio. Tutte queste azioni
permettono di traslare la curva del profilo di rischio verso sinistra.
Strategie di risposta alle opportunità: A) Exploit: si cerca di rendere una data opportunità più probabile,
assegnando all'attività destra associate le risorse migliori in grado di coglierla più facilmente. B)Share: si
assegnano all'attività coloro che sono più incentivati a realizzarle al meglio.
La scelta delle azioni di risposte da implementare richiede anch'essa una valutazione. Infatti, associata tale
azione di un costo certo che fa fronte però vantaggi aleatori sia in termini di possibile riduzione di un
effetto negativo sia in termini di possibili vantaggi. Per consentire tale valutazione è necessario determinare
il beneficio al netto degli interventi. A tal fine può essere utile ad esempio calcolare la differenza tra valore
atteso del rischio prima e dopo le azioni di risposta al netto dei costi delle azioni stesse e verificare così se si
ottiene un beneficio netto positivo al termine della fase di pianificazione dell'azione di risposta possibile
arricchire il Risk Register con nuovi dati di dettaglio relativi alle azioni da implementare.
4)Definizione delle contingency: a valle dell'analisi dei rischi e dell'individuazione delle azioni di risposta da
eseguire, occorre definire l'ammontare delle contingency da allocare a fronte dei rischi residui per ogni
work package (è impossibile eliminare completamente il rischio da un progetto tramite le azioni di
risposta). L’accadimento di uno dei tali rischi porterebbe a degli extra costi per la sua gestione impattando
sulla dimensione economico-finanziaria del progetto; si decide allora di accantonare alcune contingency per
creare un "margine di sicurezza". Solitamente viene assegnato come contingency una quantità almeno pari
all'impatto atteso del rischio a valle dell'azione di risposta. Dato che le contingency sono legate a rischi
specifici è possibile collocarle nel tempo dato che è stato già definita la pianificazione temporale dei control
account; in questo modo è possibile monitorare il consumo su base temporale, misurando per ogni periodo
la quantità cantonata, quella utilizzata e quella non più necessaria.
CONTROLLO DEL RISCHIO : innanzitutto si occupa di verificare che i rischi stimati in fase iniziale vengono
opportunamente aggiornati, alla luce delle nuove informazioni che emergono durante lo sviluppo del
progetto. In alcuni casi può risultare utile adottare anche un'analisi a livello di progetto, per valutare il
grado di esposizione al rischio del progetto complessivo. La valutazione del profilo di rischio del progetto
parte dalla valutazione della distribuzione di probabilità di singoli rischi e dalla valutazione del loro impatto.
Attraverso software di simulazione numerica è possibile eseguire l'analisi di tipo Montecarlo andando a
determinare la distribuzione di probabilità degli impatti legati al verificarsi dei rischi che vengono
rappresentati mediante una curva cumulata di tale probabilità (grafico ad S probabilità[%]/impatto[€]).
Attraverso questo grafico è possibile stimare la probabilità che gli extra costi legati ai diversi rischi superino
le contingency totali allocate andando così ad erodere il margine di progetto. Man mano che il progetto
avanzerà la curva del profilo di rischio si sposterà verso sinistra indicando che il profilo di rischio dell’intero
progetto si sta riducendo.
Gestione di progetto
Un progetto si caratterizza per l'unicità dell'output, nelle modalità di realizzazione, dalla specificità degli
obiettivi definiti perseguiti, dalla durata limitata nel tempo, dalla necessità di reperire e di coordinare
diverse risorse. Tutte queste caratteristiche non consentono di contare sull'opportunità offerte dalla
continuità dei processi nel tempo ed alla conseguente possibilità di affinamento delle soluzioni di
apprendimento progressivo. Queste caratteristiche invece richiedono di individuare e di adottare le
soluzioni appropriate definendole caso per caso a partire quando possibile da esperienze simili. I progetti
presentano così alcune problematiche tipiche che richiedono approcci e soluzioni specifiche. Un progetto
viene realizzato in condizioni non del tutto definite in presenza di elementi di incertezza più o meno
marcati; si configura così come un processo di problemi solving cioè un processo decisionale volto ad
individuare una soluzione soddisfacente per uno specifico problema nel rispetto degli obiettivi e dei vincoli
noti. Il progetto stesso diventa così la combinazione di un insieme di processi decisionali. Tuttavia può
capitare che la soluzione individuata non sia congruente con gli obiettivi e i vincoli di altre attività e che tali
vincoli emergano solo in una fase successiva non essendo noti al momento in cui l'attività viene svolta.
Esistono tre principali classi di interdipendenza che possono verificarsi nel corso di un progetto:
1) Interdipendenza Fra Attività O Fasi Successive: nello svolgimento di fasi temporalmente e logicamente
successive emergono vincoli non considerati nello svolgimento di una fase precedente
2) Interdipendenza Fra Parti Del Progetto: le scelte progettuali fatte nello sviluppo di parti diverse del
progetto non sono tra loro coerenti e richiedono un ripensamento delle scelte fatte.
3) Interdipendenze Fra Progetti Diversi: le decisioni prese nella realizzazione di un progetto risultano
incongruenti con quanto deciso per altri progetti correlati.
A causa di questi interdipendenze può accadere che la soluzione che appare migliore o soddisfacente
all'interno di una specifica attività non lo sia invece a livello di progetto (il massimo locale non è sempre un
massimo globale); la difficoltà nel caso di un progetto nasce dal fatto che non tutti i legami esistenti fra
l'attività sono conosciuti e vincoli esterni non sono sempre completamente esplicitati. Tutto ciò può
provocare degli effetti negativi sul progetto:
1) Ricicli: vengono riconsiderate le scelte fatte in precedenza modificando la soluzione adottata per
renderla compatibile con i vincoli emersi successivamente; ciò induce una perdita di tempo e di risorse per
eseguire un'attività già svolta e considerata conclusa.
2) Rimandare La Soluzione Dei Problemi Alle Fasi Successive
3) Degrado Della Qualità Dell'Output: si può essere costretti a rivedere lo scope di progetto rinunciando a
risolvere il problema qualora i costi tempi di una modifica si rivelino ormai troppo elevati; risulta essere una
scelta conveniente sul breve termine ma non sul lungo periodo a causa della perdita d'immagine aziendale.
Ci si trova dunque di fronte ad un
trade-off tra due aspetti: da una
parte l'incertezza e dall'altra il
costo e il tempo necessario per
realizzare un intervento correttivo
(figura). I ricicli sono fortemente
legati all’incertezza associata al
progetto; esistono fattori di
incertezza interni (associati a
elementi propri del progetto non
chiaramente identificati nelle fasi
iniziali) e fattori di incertezza
esterni (legati tipicamente al
contesto esterno in cui viene realizzato il progetto). Dalla figura si può vedere come l'incertezza è di solito
molto elevata negli stadi iniziali a causa anche dell'unicità del progetto. Man mano che si sviluppa il
progetto l'incertezza tende a diminuire dato che vengono prese decisioni che limitano l'ambito delle scelte
successive, si riducono le alternative aperte, emergono quali sono i problemi da risolvere, vengono
elaborate le informazioni necessarie per gestire le diverse parti del progetto. L'incertezza viene meno fine
progetto quando le scelte sono completamente definite e ne sono chiari gli effetti. È evidente che nelle fasi
iniziali e difficile identificare la soluzione giusta e invece emerge progressivamente nel corso del progetto.
Per tale ragione nelle prime fasi conviene dedicare tempo all'analisi di progetto proprio per ridurne
l'incertezza (è possibile acquisire conoscenza tramite l'intervento degli stakeholders). I tempi e i costi
necessari per realizzare un intervento correttivo presentano invece l'andamento opposto. All'inizio del
progetto le modifiche possono essere implementate senza difficoltà: avendo avviato da poco l’ attività, un
eventuale cambiamento non comporta problemi. Man mano che il progetto evolve però la realizzazione di
un intervento correttivo diventa sempre più onerosa a causa del fatto che anche piccoli cambiamenti
possono richiedere la revisione delle soluzioni assordate e di riprendere attività ormai completate. Per
questo dopo un certo punto conviene evitare di apportare modifiche al progetto a causa degli alti costi. Il
progetto può essere realmente gestito nelle fasi in cui l'incertezza non è troppo elevata ed è ancora
possibile modificare le scelte fatte (FINESTRA DELL'OPPORTUNITÀ). A questo scopo è necessario fare leva
su due principi chiave:
1) Anticipazione Dei Vincoli e Delle Opportunità  obiettivo la riduzione dell'incertezza nelle fasi iniziali del
progetto tramite l'abbassamento della curva dell'incertezza. Per far ciò è necessario quindi anticipare il più
possibile l'esame dei vincoli e delle opportunità che emergeranno nel corso del progetto o che potranno
interessare l'output lungo tutto il suo ciclo di vita. Questo punto di vista la fase più importante del progetto
è quella di planning dove si determineranno i modi in cui verranno consumate le risorse e impiegato il
Tempo Durante La Realizzazione. Anticipazione Può Essere Realizzata Mediante Tre Categorie Di Interventi:
A) Coinvolgimento Anticipato Degli Stakeholders  vengono coinvolti tutti coloro che sono
portatori di vincoli/opportunità al progetto (cioè gli stakeholders) fin dalle fasi iniziali dello stesso.
In questa fase è necessario far leva sul lavoro in team ed è compito di chi è responsabile del
progetto individuare quali attori possono dare un contributo importante a questa fase. Gli
stakeholders dovranno essere consultati in modo da verificare che la strada che si sta
intraprendendo sia coerente con i vincoli e consideri per tempo le diverse opportunità. Un altro
strumento importante di coinvolgimento degli stakeholders è data dalla definizione di opportuni
momenti di validazione; fin dalle prime fasi del progetto sarà necessario istituire opportuni
momenti di revisione delle decisioni prese, volte ad avere una verifica da parte degli stakeholders e
una loro formale accettazione di quanto si è stabilito fino a quel momento a livello di progetto (es.
design review)
B) Gestione Della Conoscenza  anticipazione dei vincoli e delle opportunità avviene grazie alle
conoscenze acquisite in altre esperienze simili da parte del team di progetto oppure possono esser
utilizzate conoscenze intenzionalmente codificate e strutturate per essere di supporto
nell'affrontare specifici problemi (elaborazione delle design rules). Il ricorso alle conoscenze
pregresse è un potente strumento in quanto consente di identificare a priori problemi e soluzioni
che possono essere rilevanti anche nel caso di un nuovo progetto; tuttavia a volte l'esperienza
pregressa può comportare un effetto di blocco (lock-in) a causa del fatto che i nuovi progetti
vengono affrontati privilegiando l'uso di metodi e approcci applicati con successo in progetti
precedenti a prescindere dalla loro efficacia. Nel caso di progetti radicalmente nuovi occorre far
leva sulla sperimentazione a causa dell'impossibilità di utilizzare esperienze precedenti;
- Test Validativi: sono utili per verificare gli impatti delle scelte effettuate e il rispetto di specifici
requisiti (es. crash test per nuove auto). Questa tipologia di test viene effettuata nelle fasi finali
della progettazione; nel caso venissero riscontrati dei problemi, la loro soluzione richiederebbe
l'attuazione di ricicli complessi e onerosi;
- Test Esplorativi: sono utilizzati per mettere alla prova le soluzioni ipotizzate grazie a prove
realizzate durante lo sviluppo stesso del progetto; ciò permette di anticipare vincoli opportunità al
contrario del caso precedente.
C) Adozione Di Un Metodo  l'applicazione di metodi strutturati infatti induce ad affrontare in
modo sistematico specifici aspetti del progetto riducendo così il rischio di rinviare l'analisi e la
messa in evidenza di possibili problemi; vengono utilizzati modelli di analisi che possono migliorare
la comprensione delle problematiche di progetto e molto spesso queste metodologie sono
progettate per specifiche tipologie di progetti.
2) Flessibilità  obiettivo riduzione dei tempi e dei costi delle modifiche di progetto tramite
l'abbassamento della curva dei costi e dei tempi di modifica. Questa filosofia è molto utile in condizioni di
alta incertezza (es. sistemi in forte evoluzione) nei quali non è possibile anticipare i vincoli poiché non si
conoscono minimamente. Con flessibilità s'intende la capacità di un progetto e dell'organizzazione che lo
gestisce, di contenere gli impatti e gli oneri derivanti da interventi correttivi effettuati in fase avanzata del
progetto. La flessibilità quindi tende a ridurre la pendenza della curva dei tempi dei costi per la
realizzazione di un intervento correttivo e quindi la loro entità nelle fasi finali di un progetto. La flessibilità
ovviamente comporta un aumento dei costi di progetto a fronte però della riduzione dei costi attesi nel
caso di cambiamenti; quindi ha senso investire sulla flessibilità se e solo se si ritiene altamente probabile di
dover introdurre cambiamenti al progetto durante le fasi conclusive; Esistono tre principali tipologie per
applicare il principio di flessibilità:
A) Processo  si agisce sul processo, sulla sequenza sulle relazioni tra fasi di attività secondo un
approccio non tradizionale. Quando si applica l'approccio flessibile, si accetta che le particolari
condizioni esterne possano mutare; di conseguenza tornare indietro e modificare alcune decisioni
non è più considerato sintomo di errore ma una necessità o una opportunità da sfruttare. Per far
ciò l'approccio da adottare deve essere differente. E necessario in particolare sottoporre
rapidamente attesta le soluzioni ipotizzate per testarne la bontà e introdurre le integrazioni e le
modifiche necessarie generando così nuova conoscenza utile nel prosieguo del progetto. A questo
scopo le fasi e le attività saranno temporalmente sovrapposte (overlapping) e si cercherà non
appena possibile, di costruire prototipi (beta release) almeno parzialmente funzionanti da testare,
anche con il coinvolgimento degli utenti, per raccoglierne i feedback e rivedere di conseguenza le
scelte fatte le soluzioni adottate (identificazione bachi, interesse per le funzionalità proposte,
suggerimenti e osservazioni). La gestione delle modifiche nel corso dello svolgimento del progetto
comporta ingenti costi di lavorazione duplicazione degli sforzi ma d'altro canto permette di avere
un prodotto aderente alle aspettative del cliente (cioè non obsoleto) e privo di bachi.
B) Risorse  vengono messe a disposizione di un progetto persone con elevate competenze
(overskilling) rendendo così più facile realizzare integrazioni e modifiche nel corso del progetto.
L’overskilling comporta un costo aggiuntivo dovuto alle maggiori competenze allocate al progetto
che però è più che controbilanciato dai tempi dei costi risparmiati per introdurre le successive
modifiche dovute per esempio ad innovazioni.
C) Architettura Modulare  l'architettura di un prodotto o di un servizio è dato dall'insieme delle
sue parti e delle logiche attraverso cui esse interagiscono. Nell'architettura modulare ogni
componente svolge una sola funzione (il componente viene detto modulo) e ciò aumenta la
flessibilità nella gestione del progetto. I vantaggi sono molteplici e interessano sia la progettazione,
sia la produzione, la logistica, il servizio postvendita, ecc. Grazie quest'architettura, qualora si
volesse modificare una funzione in fase avanzata dello sviluppo, sarebbe necessario agire su una
solo modulo lasciando gli altri invariati. Questa tipologia di architettura inoltre agevola la modifica
anche nelle fasi finali riducendo il tempo è il costo della riprogettazione. Non bisogna dimenticare
però che i costi derivanti da tale scelta possono essere fino al 20% più alti a causa della maggior
richiesta di tempo e risorse per la definizione dell'architettura.
Organizzazione di progetto
I progetti sono finalizzati al raggiungimento di obiettivi specifici e prevedono la messa in opera di un
insieme di attività necessarie a realizzare l'output. È necessario quindi identificare una struttura
organizzativa specificamente incaricata di realizzare il progetto. Il coordinamento risulta molto spesso
critico a causa della collaborazione e integrazione tra funzioni organizzative differenti.
Scelta Della Forma Organizzativa : dato che non esiste un unico modello organizzativo a validità generale, è
necessario scegliere un'organizzazione coerente con le problematiche da gestire con le caratteristiche del
contesto di progetto. Dato che l'azienda dispone già di una vera e propria struttura organizzativa
consolidata, non conviene modificarla ogni volta venga avviato un nuovo progetto, ma ci si limita a
introdurre le integrazioni appropriate caso per caso. Tre configurazioni principali:
1) Organizzazione Funzionale  il progetto viene scomposto in sottoprogetti ed ognuno è assegnato a una
specifica funzione dell'impresa. I sottoprogetti sono svolti da personale assegnato a tempo parziale a
quell'attività e la loro responsabilità è affidata ai manager funzionali. All'inizio del progetti i responsabili
funzionari sviluppano assieme il piano e identificano i sottoprogetti di cui ognuno di loro si occupa
separatamente; periodicamente si ritroveranno a integrare risultati e a verificare lo stato di avanzamento.
Punti Di Forza: - semplice da gestire
- efficacia nell'uso delle risorse
Punti Deboli : - problemi di coordinamento e di orientamento al risultato
- scarsa efficacia progettuale
2) Organizzazione Task Force  viene nominato un PM responsabile del progetto, il quale risponde
direttamente al committente. Le risorse sono assegnate a tempo pieno per tutta la durata del progetto e
rispondono solo al PM. Si viene quindi a creare una sorta di unità organizzativa autonoma ma temporanea
(al termine del progetto la TF si scioglie).
Punti Di Forza: - il PM e le risorse sono esclusivamente focalizzate sul progetto
- team fortemente coeso e non soggetto a interferenze di altre attività
- facilità di coordinamento e forte orientamento al risultato
Punti Deboli : - dispendiosa in termini di duplicazione di risorse
- inefficienza nei tempi morti del progetto
- distacco dei membri del team delle funzioni di appartenenza (perdita di contatto rispetto agli
sviluppi nelle proprie discipline di riferimento)
- problemi di gestione delle risorse umane al momento dello scioglimento
3) Organizzazione A Matrice  entrambi i casi precedenti mostrano un problema nell'equilibrio fra
l'obiettivo di lungo termine delle unità specialistiche (accrescimento conoscenza tecnica) e gli obiettivi di
breve termine dei singoli progetti. La struttura a matrice media tra queste due situazioni. Come nella TF
viene nominato un PM che può essere parzialmente o totalmente responsabili degli obiettivi. I membri del
team non vengono staccati dalle funzioni di appartenenza, ma vengono assegnati al progetto solo per una
porzione di tempo. Nella matrice di timo possono essere organizzati in modo trasversale rispetto le funzioni
e quindi avremo team interfunzionali e multidisciplinari.
Punti Di Forza: - orientata al risultato senza compromettere l'efficienza delle risorse (le risorse
continueranno a lavorare nelle loro funzioni per il tempo non impegnato nel progetto)
Punti Deboli : - complessità di gestione a causa dei conflitti tra PM e responsabili funzionari sulle modalità e
le priorità nell'accedere alle risorse e sulle scelte progettuali
- il PM responsabile dei risultati ma non ha una autorità completa per agire sulle risorse
- i membri del team continuano a risentire dei disturbi provenienti da altre attività
4) Soluzioni Intermedie
A) Matrice Debole  non vengono modificati, se non marginalmente, i ruoli e poteri della struttura
organizzativa aziendale. Il PM ha responsabilità limitata sui risultati da ottenere; si limita a facilitare
i rapporti tra le unità organizzative coinvolte nel progetto e nel sollecitare il rispetto delle scadenze
concordate. Il PM può seguire più progetti contemporaneamente.
B) Matrice Forte  Il PM ha un potere decisionale maggiore ed è direttamente responsabile di
tutte le prestazioni di progetto ed ha il controllo sull’utilizzo delle risorse anche se queste
rimangono all’interno delle proprie unità funzionali. Il PM è concentrato su un unico progetto.
C) Matrice Mista o Bilanciata  Il PM assume un ruolo di coordinatore e pianificatore delle risorse
con la possibilità di negoziare l’uso delle risorse con i responsabili funzionali.
Condizioni Di Applicazione
1) Rilevanza Del Progetto  in un progetto particolarmente importante per l'impresa, per il quale non è
ammesso commettere errori, che può influenzare drammaticamente le performance dell'impresa, risulta
preferibile adottare una struttura forte; gli obiettivi funzionali vengono posti in secondo ordine rispetto a
quelli di progetto su cui si devono concentrare l'attenzione e gli sforzi dell'organizzazione. La rilevanza
(economica e strategica) del progetto rende anche giustificata l'allocazione in modo esclusivo di risorse al
progetto, cosa invece più difficile da accettare di fronte a progetti poco importanti.
2) Criticità Degli Obiettivi  l'elevata criticità degli obiettivi di progetto impone la preferenza per una
struttura forte. Il termine di un progetto spesso coincide con eventi non controllabili (fiere, lancio di
prodotti concorrenti) e in tale situazione terminare il progetto poco prima o poco dopo la data prevista può
avere impatti molto diversi sul successo del progetto. In caso di progetto su commessa la consegna oltre
termine obbliga al pagamento di onerose penali
3) Novità Del Progetto  progetti caratterizzati da una notevole ripetitività possono essere gestiti in modo
sufficientemente efficace dalla struttura funzionale dell'impresa o da una struttura a matrice debole.
Laddove invece il progetto presenti novità importanti è preferibile virare verso una struttura forte per
diversi motivi; uno di questi è che operando in maniera del tutto nuova si eviterà il rischio di limitarsi ad
applicare solo soluzioni affermate e consolidate a un progetto che per la sua novità richiede invece
soluzioni particolari.
Fattori Da Considerare Nella Scelta Del Modello Organizzativo
1) Contributo Del PM Al Progetto  l'adozione di una struttura forte richiede di poter disporre di un PM in
grado di governare il progetto dotato delle competenze manageriali tecniche necessarie.
2) Rilascio Delle Risorse Al Termine Del Progetto  al termine del progetto le risorse rientrano nelle loro
unità organizzative di appartenenza; la permanenza, anche se temporanea, fuori dalla propria funzione può
rendere difficile il reinserimento, a fronte di cambiamenti intervenuti nel frattempo in fatto di procedure
aziendali o di assegnazione delle mansioni. Coloro che rimangono nella funzione sviluppano una crescita
della conoscenza specialistica mentre chi lavora la task force aumenta la propria conoscenza trasversale su
altri campi di applicazione; crescita conoscenza trasversale >>> crescita conoscenza specialistica.
3) Sistemi Valutazioni Performance  nel caso di strutture forti la responsabilità risulta in capo al PM
mentre in quelle deboli la responsabilità è del responsabile funzionale. Nel caso di soluzioni miste la
valutazione più complessa e rende necessario creare sistemi di rapporti per il controllo dei consumi delle
risorse; vengono stilati dei time sheet periodici relativi al tempo speso da parte di ciascun individuo nelle
singole attività (così viene tracciato il contributo delle funzioni al progetto). L'applicazione risulta semplice
in teoria ma in pratica è molto più complessa a causa del tempo necessario richiesto per la compilazione e
per la discrezionalità nell'attribuzione del proprio tempo da parte delle risorse.
Definizione dei ruoli
1) PM  è responsabile del raggiungimento degli obiettivi specifici del progetto, garantisce l'integrazione
tra le diverse parti e risolve problemi che eventualmente si generano durante lo sviluppo. Nelle strutture
deboli ha un controllo limitato sul progetto ed è tipicamente focalizzato sulla pianificazione il controllo; si
occupa di concordare con le risorse il loro contributo per portare a compimento le diverse attività e ne
facilita il coordinamento. In questo caso il PM non ha un controllo sulle risorse, compito che svolto
direttamente da responsabili funzionali; inoltre non gestisce gli aspetti tecnici del progetto che rimangono
affidati alle unità funzionali. Nel caso di strutture forti il PM ha un controllo diretto sulle scelte di progetto;
gestisce direttamente le risorse, negoziandone l'utilizzo con i responsabili funzionali, ai quali compete
comunque la decisione su quali risorse da allocare a fronte delle richieste del PM. Inoltre il PM gestisce la
pianificazione il controllo delle attività e per questo ha solitamente un livello di competenze tecniche
sufficienti relativamente allo scope di progetto.
A) Autorità  in relazione alle caratteristiche del progetto è opportuno conferire al PM un certo
grado di autorità. L'autorità formale del PM dipende da diversi fattori: dalla posizione gerarchica del
livello organizzativo cui è collocato il PM stesso, dai poteri a lui delegati dalla direzione, dal livello
gerarchico della committenza a cui riferisce (es. se riferisce all'amministratore delegato la sua
autorità sarà elevata) e dal suo coinvolgimento nei sistemi di valutazione delle risorse. L'autorità
conferita ad essere commisurata alle responsabilità del PM.
B) Autorevolezza  condiziona la capacità del PM di influenzare e motivare le risorse nello
svolgimento del loro compiti. Essa dipende innanzitutto dalle sue competenze tecniche, che devono
essere tali da renderlo credibile agli occhi dei suoi collaboratori nel prendere le decisioni necessarie
nel corso del progetto. Dipende inoltre dalle sue competenze gestionali (capacità di indirizzare
coordinare e controllare le attività e le risorse) e da ultimo dipende dal suo stile di leadership,
ovvero dalla sua capacità di motivare le persone al massimo. Autorevolezza costituisce una
caratteristica personale non facilmente modificabili nel breve termine.
È molto importante che entrambe queste caratteristiche siano bilanciate e commisurate al tipo di
ruolo affidato al PM, per evitare che insorgano difficoltà ed egli non riesca a svolgerlo
adeguatamente.
2) Functional Project Leader  nel caso di progetti di grosse dimensioni diventa difficile per il pm
assicurarne direttamente il coordinamento e la supervisione; in questi casi viene affiancato dai FPL, ovvero
dei tecnici afferenti a diverse unità organizzative incaricati di gestire, su delega del PM, porzioni importanti
dell'attività di progetto (di solito hanno la responsabilità di una specifica unità organizzativa come
progettazione, produzione, acquisti). In altri termini il FPL è un PM operativo focalizzato su una specifica
funzione o su un particolare sottoinsieme di attività.
3) Risk Manager  supporta il PM nell'identificazione nella gestione dei fattori di rischio associati al
progetto; verifica che la gestione del rischio sia coerente con la specifica tipologia di progetto (esame di
tutte le aree di rischio rilevanti e verifica delle azioni correttive richieste)
4) Contract Manager  supporta il PM nel gestire in modo giuridicamente corretto i differenti aspetti del
progetto, in particolare monitorando le varie attività alla luce dei vincoli e degli obblighi, definiti nel
contratto, verso il cliente e verso possibili altri partner (licenze, penali, ecc.)
5) Responsabili Funzionali  hanno il compito di gestire le risorse le attività di loro competenza dedicate al
progetto. Il loro ruolo è strettamente legato a quello del PM: al crescere del "peso" del PM diminuisce
quello dei responsabili funzionali. Rimangono comunque di pertinenza delle funzioni tutte le attività di
sviluppo delle risorse e il presidio delle competenze funzionali stessa.
PIANIFICAZIONE
Innanzitutto sia la pianificazione dello scope di progetto e tale attività permette di creare la lista delle
attività che devono essere svolte cioè la WBS (Work Breakdown Structure). In modo parallelo è necessario
definire un piano delle risorse disponibili sul progetto (OBS Organizational Breakdown Structure). L'unione
di queste due “viste” viene effettuata tramite la RAM (Responsabilty Assignment Matrix) che permette di
ottenere il mattone di base del processo di pianificazione, costituito del Control Account, cui è possibile
associare tempi, costi e rischi. La successive integrazioni tutte queste informazioni generate al livello di
progetto complessivo permettere pianificazione del tempo di progetto (Schedule), del suo costo (Budget) e
della visione sinottica di essi (Baseline).
Gestione Dello Scope
Lo scope è dato dall'insieme di prodotti, servizi e risultati che devono essere forniti come output di un
progetto. La gestione dello scope è definita come sotto processo che assicura che il progetto includa tutto il
lavoro richiesto e solo il lavoro richiesto per completare il progetto con successo. L'input principale è dato
dal project charter validato durante la fase di inizializzazione. Il processo di gestione dello scope l'obiettivo
di garantire la realizzazione di quanto richiesto dal cliente, interno o esterno che stia, evitando però di
realizzare più di quanto richiesto, per non incorrere i maggiori tempi e costi di progetto. Fasi fondamentali:
A) Pianificazione Dello Scope  questa fase l'obiettivo di definire come lo scope sarà gestito verificato e
controllato e come sarà realizzata la WBS di progetto e come sarà verificata la completezza.
B) Definizione Dello Scope  in questa fase tutte le richieste degli stakeholders vengono analizzati
convertiti requisiti, grazie allo sviluppo del cosiddetto scope statement. Questo è un documento che
descrive cosa il progetto voglia realizzare in modo sufficientemente dettagliato. Il ruolo di questo
documento e quindi chiarire cosa il cliente e gli altri stakeholders si aspettano dal progetto. Info contenute:
-Obiettivi Del Progetto (descrizione degli obiettivi specifici del progetto dei fattori che hanno motivato il suo
sviluppo) -Descrizione Dell'Output (prescrizione tecnico sistemica della soluzione proposta di come questa
rispetta gli obiettivi specifici) -Deliverable (output tangibili o assimilabili che il progetto realizzerà durante il
suo sviluppo) -Criteri Di Completamento (criteri che permettono di accettare i deliverable generati e quindi
di proseguire nelle fasi successive) -Vincoli Di Progetto (vincoli associate al progetto in termini di persone,
risorse, attori da coinvolgere, attrezzature) -Misure Di Successo (parametri di prestazione che sono dotati
per valutare il successo del progetto sia internamente sia verso il cliente) -Ruoli E Stakeholders Principali Linee Guida E Approccio (linee guida in fatto di outsourcing e di interazione con il cliente) -Stime Preliminari
Di Tempi E Costi -Sistemi Di Controllo -Autorizzazioni
C) Creazione WBS  in questa fase sono identificate tutte le sole attività necessarie al raggiungimento
degli obiettivi di progetto. Il processo di costruzione della WBS si basa sulla scomposizione gerarchica che
consente di identificare gradualmente le attività elementari di progetto a partire dai deliverable concordati
con il cliente e gli altri stakeholders di progetto.
D) Verifica Dello Scope  in questa fase viene l'approvazione formale dei deliverable di progetto da parte
di tutti gli stakeholders. La verifica dello scope richiede quindi momenti di revisione intermedi in cui
l'output di progetto viene gradualmente approvato permettendo lo sviluppo del progetto stesso nelle
diverse fasi del suo ciclo di vita. A chiusura di questa fase coincide con la pianificazione definitiva dello
scope di progetto.
E) Controllo Dello Scope  a valle delle fasi di pianificazione si attiveranno le attività di controllo dello
scope durante lo svolgimento del progetto, grazie alle quali saranno gestiti tutti i cambiamenti di esso e gli
impatti sul progetto.
Creazione della WBS  la WBS è uno strumento che, attraverso una logica gerarchica, decompone in modo
sistematico il progetto in aggregati di attività sempre più piccoli, fino ad arrivare ad identificarne le attività
e i pacchetti di lavoro elementare. L'obiettivo della WBS è quello di supportare la definizione del lavoro
necessario per ottenere un determinato risultato, illustrando parallelamente la struttura gerarchica dei
deliverable di progetto. La costruzione richiede lo svolgimento di un processo iterativo fatto per
approssimazioni successive; a partire da una identificazione delle macro attività principali, tali micro attività
sono a loro volta suddivisi attività più semplice ricorrendo all'organizzazione di progetto è quindi utilizzando
competenze specifiche per ogni macro attività. Ogni elemento della WBS è chiamato WBE (Work
Breakdown Element) mentre nel caso del livello più basso della WBS tale elemento viene comunemente
chiamato Work Package (WP). Esistono ovviamente diverse logiche con cui disaggregare le attività di un
progetto. Ad esempio si ha la scomposizione in base alle parti fisiche che costituiscono un certo deliverable,
oppure quella in base alle fasi necessarie per realizzarlo o in base a rilasci progressivi dell'output, ecc.
l'obiettivo prima della segmentazione del progetto è quello di semplificar nella gestione, limitando al
massimo la perdita di integrazione. Occorre identificare, ciascun livello, insieme di attività che, all'interno
dell'aggregato, siano tra loro fortemente interconnesse. Ciò è finalizzato a ridurre problemi di
coordinamento. Inoltre occorre evitare ridondanze. È opportuno adottare sempre un'unica logica di
disaggregazione per ogni nodo della WBS.
Linee Guida: A) ogni WBE può essere ulteriormente segmentato usando una sola logica di scomposizione
(logiche diverse possono essere usate per livelli differenti o per altri nodi sullo stesso livello)
B) la profondità (intesa come numero di livelli) della WBS dipende dalle dimensioni e dalla complessità del
progetto ed a livello di dettaglio necessarie per pianificarlo
C) ad ogni livello, ciascun WBE deve deve poter essere chiaramente definite in termini di responsabilità
D) all'interno della WBS devono essere presenti tutti i deliverable (esterni interni) di progetto
E) insieme di tutti i WBE di un livello della WBS deve scrivere l'intero progetto
F) la struttura della WBS indipendente da qualsiasi legame temporale. Le sequenze logiche su un problema
di pianificazione temporale (scheduling) ed esulano dagli obiettivi della WBS.
Controllo Dello Scope  dal momento di inizio del processo di controllo dello scopo può essere possibile
che avvengano cambiamenti significativi nel tempo; vi possono essere numerosi fattori che portano a
cambiamenti di scope di progetto
A) Scope Creep  si intendono tutte quelle situazioni in cui un cambiamento del progetto fronte di
richieste del cliente, che comportano la realizzazione di lavoro non previsto nel piano iniziale. Capita spesso
quando le richieste iniziali del cliente non sono chiare, ma soprattutto quando, durante il progetto, non vi
sono opportuni momenti di congelamento delle specifiche con il cliente. Il problema è che in molti casi tali
modifiche impattano sulle altre prestazioni di progetto (tipicamente i tempi e costi di realizzazione), ma
non si provvede o non si riesce a ribaltare tali effetti sull'cliente, che continuerà ad aspettarsi l'output
concordato nei tempi e con i costi definiti. Questo fenomeno difficilmente si manifesta con grande
significativi cambiamenti ma come una sequenza ininterrotta di piccoli cambiamenti (l'impatto di ognuno
dei quali probabilmente minimo, ma la loro somma molto significativa)
B) Scope Gold Plating  in questo caso si alla realizzazione di lavoro aggiuntivo che porta sviluppa le
funzionalità o a erogare prestazioni che il cliente non richiede e a cui non attribuisce un valore specifico.
Anche in questo caso dell'impossibilità di ribaltare gli impatti sui tempi e sui costi di progetto sul cliente;
spesso tale fenomeno si verifica a causa di una non chiara definizione interna delle attività da svolgere e a
fronte di una descrizione non dettagliata dello scopo di attività elementari. Questo fenomeno solitamente è
causato direttamente dall'impresa che gestisce il progetto, spesso dalle funzioni tecniche, che nella ricerca
dell'ottimizzazione realizzano più di quanto richiesto dal cliente.
Gestione Scope Change  e necessario definire un processo di gestione monitoraggio dei cambiamenti di
scope al fine di limitare i fenomeni visti. Tale processo è costituito da cinque fasi fondamentali:
A) Identificazione e Documentazione  ogniqualvolta si presenta necessità o richiesta di una modifica, è
necessario documentare tale richiesta, citandone la fonte e la motivazione.
B) Condivisione E Approvazione Interna  la richiesta deve essere condivisa all'interno del team di
progetto in quanto il lavoro degli altri membri del team potrebbe subire modifiche a causa della richiesta.
C) Validazione Da Parte Del Cliente  la richiesta di cambiamento deve essere valutata in termini di
fattibilità, impatti sui tempi, costi e rischi di progetto deve essere richiesta al cliente una autorizzazione a
procedere al cambiamento.
D) Aggiornamento Della Pianificazione  una volta autorizzato il cambiamento da parte del cliente, deve
essere aggiornata la WBS di progetto e quindi a cascata anche i tempi, i rischi, l'organizzazione, i costi, ecc.
E) Autorizzazione  è necessaria la forma autorizzazione a procedere con il cambiamento da parte della
committenza di progetto.
Organizzazione Di Progetto Di Allocazione Delle Responsabilità
Una volta definita la tipologia di strutture da adottare per uno specifico progetto, identificate le funzioni
coinvolte ed eventualmente le risorse assegnate al progetto, tali informazioni vengono sintetizzate
mediante la OBS (Organization Breakdown Structure) che di fatto è un organigramma del progetto, volta
individuare tutti gli attori coinvolti e a definire la struttura di governo. Il PM supervisione del progetto
complessivo che coordina il progetto al livello dei Functional Project Leader i quali sono responsabili di
coordinare le proprie risorse nello svolgimento del loro pacchetti di lavoro. Strumento che supporta il
disegno mentre più di dettaglio del progetto, tramite l'allocazione delle risorse alle attività e la definizione
del loro ruolo, è la cosiddetta RAM (cioè la Responsability Assignement Matrix). Si tratta di una schiera
amatrice, che riporta sulle righe le diverse attività (ad esempio i work package derivanti dalla WBS) e sulle
colonne le unità organizzative, ai diversi livelli della struttura aziendale, coinvolte a vario titolo nel progetto.
All'incrocio tra unità organizzativa e le attività si definiscono il ruolo svolto nel progetto e relativo livello di
responsabilità esistono diversi tipi di codifica per identificare le responsabilità e il tipo di contributo
richiesta ad ogni unità organizzativa (responsabile, di supporto, consulente, informato, colui che firma,
coliche verifica, colui che approva)
Control Account
Il control account è definito come il blocco di controllo manageriale cui possibile attribuire uno scope
specifico e delle stime di tempo, costo e il rischio. È definito dall'incrocio tra la descrizione dell'elemento di
WBS (cioè il WBE) da svolgere e le risorse allocate a tale WBE derivante dalla OBS. Risulta dunque evidente
come la RAM descritta sia uno degli strumenti principali per la definizione di un control account. Il control
account e quindi, da un lato, il blocco informativo principale per la pianificazione di un progetto e, dall'altro,
è anche l'unità di analisi principale del processo di controllo. Aggregando i costi dei singoli CA, si otterrà il
costo totale di progetto; aggregando i tempi dei singoli CA, si otterrà il tempo totale di progetto (bisogna
tenere conto delle precedenze logiche tre pacchetti di lavoro); aggregando le stime dei dischi dei singoli CA
si otterrà il rischio totale di progetto (mediante opportuni calcoli statistici). Il processo che permette di
allocare a un control account una stima dei tempi dei costi e un processo complesso dato che il tempo e il
costo di una attività non sono caratteristiche intrinseche dell'attività stessa (lo stesso WBE potrebbe avere
tempi e costi differenti a seconda delle risorse assegnate). Il processo di definizione della durata, e quindi
del costo, di un control account è composto da diversi passi:
A) Definizione Dell'Output Del Control Account (in modo tale da permettere l'identificazione delle risorse
necessarie e quantificare il lavoro)
B) Allocazione Risorse (quante e quali risorse assegnare al control account)
Durata CA = (Lavoro Necessario*Fattori Correttivi)/(Produttività*Risorse Allocate)
Il parametro di produttività dipende dalla reale livello di competenza delle risorse e dalla loro esperienza
nello svolgimento di attività simili (ricavato attraverso analisi storica delle passate performance delle
risorse); i fattori correttivi sono dovuti alle diseconomie organizzative che si vengono a creare quando
l'allocazione di più risorse alla stessa attività genera la necessità di un'attività di coordinamento per il cui
svolgimento è necessario tempo addizionale.
Costo CA = sommatoria dei costi di tutte le risorse * Durata CA
Così calcolato il costo tiene conto solo delle risorse interne; adesso andranno aggiunti i costi relativi ad
esempio gli acquisti di beni e servizi necessari per lo svolgimento delle attività. Considerazioni:
A) non sempre la durata dell'attività può essere ridotto aumentando le risorse allocate poiché alcune
attività hanno delle durate minime sotto le quali non è possibile scendere;
B) l'aumento del numero di risorse può comportare anche delle diseconomie organizzative a causa
dell'aumento delle attività di coordinamento necessarie;
C) alcune attività non possono poi essere suddivise su più risorse perché costituiscono un tutt'uno non
separabile.
Anche la pianificazione dell'allocazione delle risorse la gestione delle risorse umane impattano
notevolmente sulla definizione del tempo di costo, in quanto bisogna tenere in considerazione che la stessa
risorse non potrà essere impiegata tempo pieno su due distinti CA contemporanei.
Pianificazione dei tempi
Questa fase l'obiettivo di definire la distribuzione temporale delle attività (WP) e delle scadenze
(milestone). L'input fondamentale, anche se non unico, per lo sviluppo dello schedule di progetto sono le
stime di tempo dei CA. A partire da questi, lo sviluppo dello schedule di progetto richiede di operare
seguenti passi:
A) definire la sequenza logico/temporale e le relazioni tra le attività di progetto (tecniche reticolari chiusa
parentesi e gestire l'incertezza sulla stima dei tempi per attività nuove (analisi PERT)
B) definire il crono programma (tramite diagramma di Gant)
C) verificare la fattibilità del piano dal punto di vista delle risorse utilizzate (logiche di resource levelling)
D) ottimizzare il piano generato (tecnica del Critical Path Method)
Tecniche Reticolari
Conoscere la durata dei singoli WP non è sufficiente per conoscere la durata dell'intero progetto, in quanto
alcuni dei WP potrebbero essere svolti in parallelo. E necessario quindi esplicitare e analizzare le relazioni
logico temporali tra le differenti attività di progetto: - Relazione Fine/Inizio (l'inizio di un'attività richiede
che una o più attività siano terminate) - Relazione Inizio/Inizio (l'inizio di un'attività è vincolato all'inizio di
un'altra) - Relazione Fine/Fine (due o più attività sono vincolate terminare allo stesso momento).
Le tecniche reticolari derivano il loro nome dal fatto di rappresentare il progetto con una rete (o reticolo),
in cui ogni nodo rappresenta l'attività di progetto. I nodi sono collegati d'archi orientati che rappresenta le
relazioni di precedenza tra le diverse attività. Le tecniche reticolari permettono di definire lo slack di ogni
attività cioè la quantità massima di ritardo che l'attività può subire senza impattare sulla durata dell'intero
progetto. Le attività che avranno slack = 0 saranno dette attività critiche mentre le altre saranno definite
attività non critiche. Con percorso critico si intende una sequenza di attività critiche che portano dall'inizio
alla fine del progetto. Il calcolo dello slack può essere eseguito tramite la caratterizzazione dell'attività in
base a quattro istanti differenti:
A) Early Start  rappresenta il primo momento in cui una data attività può iniziare rispettando i vincoli di
precedenza assegnati; l'attività potrà iniziare al più presto solo dopo la fine dell'ultima delle attività che la
precedono logicamente.
B) Late Start  rappresenta il momento entro cui una data attività deve iniziare affinché il progetto non
subisca ritardi; si calcola dati l'istante al più tardi in cui l'attività può finire senza comportare ritardo al
progetto e la sua durata.
C) Early Finish  rappresenta il primo momento in cui l'attività può terminare dati i legami di precedenza;
si ricava dati l'istante di inizio al più presto di un'attività e la sua durata.
D) Late Finish  rappresenta il momento entro cui una data attività deve terminare affinché non comporti
ritardi all'arresto del progetto; l'attività dovrà finire al più tardi precedentemente all'inizio della prima delle
sue attività successive;
Slack = LS – ES = LF – EF
Le tecniche reticolari sono strumento basilare per la pianificazione dei progetti anche se hanno ovviamente
dei limiti. Il principale di questi è che esse considerano la durata dell'attività con una variabile
deterministica. Vi sono però molti casi in cui il calcolo della durata di un'attività risulta difficile incerto
(esempio quando il grado di incertezza e molto altro). Quindi le tecniche reticolari non permettono di
analizzare il piano di progetto in termini di robustezza rispetto all'incertezza connessa lo svolgimento delle
attività.
PERT (Project Evalation and review technique)
Con il PERT si integrano le tecniche reticolari con la valutazione probabilistica delle durate delle attività. In
primo luogo, si assume che la durata di un'attività presenti un andamento probabilistico secondo la
distribuzione beta. Inoltre si assume che lo scostamento della durata reale di un'attività del suo valore
atteso sia indipendente dallo scostamento delle altre attività del loro valore attesi. In base alla prima
assunzione è possibile definire un valore medio (Durata Attesa) e una deviazione standard della durata di
un'attività. Ciò è possibile individuando tre grandezze:
- Durata Ottimistica (A) che corrisponda la minor durata necessaria per eseguire l'attività sotto l'ipotesi che
tutto proceda al meglio;
- Durata Pessimistica (B) corrisponda la maggior durata possibile per l'esecuzione dell'attività nell'ipotesi
che tutto proceda nel peggiore dei modi;
- Durata Più Probabile O Modale (M)  corrisponda alla durata che più probabilmente sarà necessario per
svolgere tale attività.
Durata Attesa = (A+4M+B)/6 Deviazione Standard = (B-A)/6
Sull’intero progetto è possibile calcolare la durata attesa come la somma delle durate attese delle attività
che lo compongono. È possibile inoltre effettuare alcune analisi sulla robustezza del piano utilizzando la
deviazione standard di progetto calcolata come la radice delle deviazioni standard delle attività sul
cammino critico al quadrato; questo valore permette di valutare quanto la durata attesa del progetto sia
una stima affidabile. Un secondo aspetto utile all'analisi del piano è il concetto di sub criticità. Nel caso di
un'attività con slack atteso positivo, quest'ultima può essere potenzialmente problematica; se un'attività ha
uno slack atteso che sommato alla durata attesa porta un valore che è inferiore alla durata pessimistica, è
possibile che l'attività diventi critica andando a impattare sulla durata dell'intero progetto. Quindi
un'attività subcritica è un'attività che non è critica in termini di valore attesi ma che presenta una
probabilità anche minima di diventare critica. SC = B – DA – SL. Se SC<0 allora lo slack che tale da consentire
una protezione anche nel caso peggiore di durata pessimistica e quindi l'attività non potrà mai diventare
critica. Se SC>0 l’attività è subcritica e quindi esiste la possibilità che l'attività diventi realtà critica.
Diagramma di Gantt
è sicuramente lo strumento più utilizzato per la descrizione del pianificazione temporale di progetto. Le sue
caratteristiche predominanti sono la semplicità e la leggibilità. Il diagramma si basa su due assi ortogonali:
lungo l'asse verticale sono elencate tutte le attività nelle quali è stato scomposto il progetto, mentre
sull'asse orizzontale compare la variabile temporale. Ciascuna attività viene rappresentato da una barra
orizzontale il cui posizionamento è determinato dalla data di inizio prevista e la cui lunghezza rappresenta
la durata stimata in sede di previsione. Sul diagramma verranno indicate in maniera diversa e le attività
critiche da quelle non critiche ed inoltre verranno indicate anche le milestone. Infine sono esplicitate le
relazioni di precedenza e sono riportate le linee continue in grassetto che indicano il reale istante di inizio
fine dell'attività già svolte per favorire il confronto con quanto è stato pianificato. Limiti: A) nel caso di
progetti complessi la lettura del diagramma può essere molto complicata, in quanto le relazioni di
precedenza possono essere non chiaramente leggibili B) non sono chiaramente visibili gli slack delle diverse
attività; quindi non è possibile valutare l'impatto dei rischi sulla pianificazione temporale dato che non è
possibile evidenziare per l'attività non critiche l'entità dei loro slack. C) lo strumento pone l'enfasi
esclusivamente sulla distribuzione temporale del progetto e non considera direttamente i costi associati
alle attività (quindi non è possibile effettuare il controllo dei costi di progetto delle risorse)
Resource Levelling
il piano temporale sviluppato fino ad ora, che tiene solo in considerazione l'le attività da svolgere, le loro
relazioni logiche e la durata, potrebbe comportare dei problemi di fattibilità gestionale infatti potrebbero
determinarsi delle sovra allocazioni di risorse e dunque la non fattibilità del piano poiché, nonostante aver
tenuto conto della disponibilità di partenza le risorse, non è stato possibile considerare il carico derivante
dalle varie attività. Per sovraallocazioni s'intende che la risorsa sarà impegnata su più di un'attività in
parallelo per una quantità superiore alla reale disponibilità (ciò comporterebbe certamente dei ritardi a
causa della non corretta pianificazione). E’ dunque opportuno effettuare un controllo sulla reale fattibilità
gestionale del piano stesso utilizzando il diagramma delle risorse, ossia uno strumento che verifica, per ogni
unità temporale di riferimento, le allocazioni di una risorsa su differenti attività di progetto normalmente
calcolati in percentuale sulla risorse disponibile. Nel caso in una certa unità temporale la risorse si allocata
per una percentuale superiore al 100% è necessario effettuare il resource levelling. Vi sono due possibilità
distinte: la prima è di aumentare le risorse di progetto, per esempio aggiungendo una nuova risorsa (spesso
tale soluzione percorribile) mentre la seconda è di evitare di far svolgere più attività in parallelo da parte di
quelle risorsa nell'unità temporale in esame. Ciò di solito ha un impatto sul tempo di progetto che tende ad
aumentare.
Critical Path Method
è un metodo euristico di analisi e ottimizzazione del piano di progetto basato sulle tecnologie reticolari. Il
CPM si basa sul fatto che spesso esiste un trede-off molto forte fra i tempi e i costi associati all'attività di
progetto. Infatti è spesso possibile variare la durata di un'attività (e quindi di un progetto) variando la
quantità o la tipologia di risorse quest'allocate, e quindi anche il suo costo. Il CPM analizza gli effetti diverse
ipotesi di allocazione delle risorse sulla durata del progetto, cercando un equilibrio tra costo è durata del
progetto che meglio risponde agli obiettivi. Per modificare la durata di un progetto è necessario agire sul
suo cammino critico in particolare su quell'attività critiche sulle quali si è maggiormente conveniente
investire. Il CPM prevede lo svolgimento della seguente procedura iterativa: A) Identificazione Cammino
Critico B) Selezione Delle Attività  viene selezionata fra l'attività del cammino critico quella su cui risulta
più conveniente agire al fine di contrarre i tempi di progetto (praticamente viene scelta l'attività con il
rapporto ΔCosto/ΔTempo più piccolo). C) Confronto Dell'Aumento Marginale Di Costo Con Beneficio
Marginale  la riduzione del tempo di progetto deve essere associata con beneficio se il costo supera il
beneficio non vale la pena ridurre la durata del progetto e l'applicazione del CPM può ritenersi conclusa.
Condizioni di arresto iterazione: 1) i costi marginali necessari per ridurre ulteriormente la durata non sono
giustificati dei benefici marginali che la riduzione permette di ottenere. 2) non è più possibile ridurre
ulteriormente alcuna attività di progetto in quanto le risorse sono state utilizzate tutte alla loro massima
capacità. 3) si creano diseconomie organizzative.
Pianificazione dei Costi
Anche per il costo, gli elementi di base della pianificazione sono i control account. Il costo di progetto,
calcolato tramite l’aggregazione e l’integrazione di dati relativi ai singoli CA, deriverà dalle risorse
consumate per svolgere le attività richieste. Approcci per stimare il costo di un control account: stima
analitica, stima logica, stima paramedica.
La stima analitica consiste in una stima dettagliata dei costi basata sull'analisi puntuale delle risorse
necessarie per ogni attività. Il vantaggio principale consiste nell'elevata accuratezza mentre lo svantaggio
principale è rappresentato dei tempi e costi di formulazione delle stime. In particolare nelle prime fasi di
progetto si utilizzano metodi più rapidi ma meno precisi. Il secondo metodo è la stima analogica: è un
metodo più rapido e non utilizza stime basate sull'analisi puntuale ma piuttosto sull'esperienza riferita ad
attività simili eseguite per progetti precedenti. Il vantaggio principale è costituito dai tempi estremamente
contenuti necessari alla formulazione a fronte tuttavia dell'elevata approssimazione delle stime. A metà
strada troviamo le stime parametriche: sono basate su parametri oggettivi e di uso comune legati a delle
particolari tipologie di risorse e di attività che permettono di fissare il costo unitario medio di particolari
risorse. Il vantaggio principale è nell'ottimo compromesso tra velocità di esecuzione e accuratezza delle
stime, mentre il principale svantaggio consiste nella sua limitata applicabilità; infatti può essere eseguita
solo esclusivamente per le attività di tipo ricorrente e per le quali è possibile disporre di una dettagliata
base di dati e costi sostenuti nel passato.
Stima Analogica  è necessario partire dalla WBS. Dato un WP, il team di progetto, avendo conoscenze
specifiche e delle attività da svolgere, può redigere l'elenco dei fabbisogni di risorse (sia interne che
esterne). Il calcolo del costo delle risorse interne si basa su una moltiplicazione del costo unitario per la
quantità di impiego. Nel caso di risorse esterne, invece, il costo equivarrà al controvalore monetario della
loro acquisizione. Questa visione di dettaglio permette di redigere Cost Breakdown Structure (CBS). La CBS
è lo strumento che consente di analizzare i costi totali di progetto, aggregandoli per natura e non per
attività. La CBS è rappresentabile attraverso un grafo ad albero: ha un solo nodo radice al più alto livello
gerarchico che rappresenta il livello di aggregazione identificato con i costi totali di progetto; eccetto il
nodo radice, ogni nodo rappresenta una categoria di costo distinta per natura e appartiene a una e una sola
categoria di costo di livello superiore. I nodi appartenenti all'ultimo livello invece rappresentano i singoli
item di costo. La matrice che si ottiene combinando la CBS e la WBS, permette di condurre l'analisi
incrociate che evidenziano: A) procedendo per riga e mantenendo fisso un elemento della CBS, la
distribuzione di ogni natura di costo sui singoli gruppi. B) procedendo per colonne e mantenendo fisso un
WP della WBS, il budget di ogni WP, dettagliato per le singole nature di costo. La CBS permette di allineare
la contabilità di progetto con la contabilità aziendale; infatti i costi sono considerati in relazione all'attività
da svolgere ma a livello di conto economico aziendale i costi sono divisi per natura e non per progetto (o
per attività di progetto).
VALUTAZIONE ECONOMICA FINANZIARIA
Un progetto ha valore se e solo se si ritiene che esso nel futuro sarà in grado di generare flussi netti di
denaro per l’impresa e per i suoi azionisti. Input Progetto: A) Input Correnti (cioè pagati e utilizzati subito): Lavoro - Prodotti e Servizi (es. materie prime) B) Input Pluriennali (non utilizzati completamente in un solo
anno): -Tecnologie (es. royalties) -Infrastrutture (es. macchinari) Output Progetto: Prodotti e/o Servizi.
Capitale Di Rischio  all'azionista non viene garantito che venga ripagato del suo investimento
Capitale Di Debito  anche in caso di fallimento la banca si riprende il capitale investito più di interessi; più
è alto il rischio sul progetto più è alto il tasso di interesse.
Il valore di progetto è dato dalla differenza nel futuro tra il valore degli output e quello degli input più
l'interesse del debito.
Lettura Finanziaria  Esborsi e Incassi (cioè Flussi di Cassa)
Lettura Economica  Costi (es. Ammortamenti) e Ricavi
Ammortamenti  Depreciation
Incasso (i) = Ricavi(i) – CC(i) + CC(i+1)
Crediti Commerciali  Account Receiveable
Esborso(i) = Cmake(i) + (Cbuy(i) – DC(i) + DC(i-1))
Debiti Commerciali  Account Payable
I crediti commerciali vengono calcolati solo sulla parte di Costo Buy!!! Ricavo  Revenue
Le due letture non sono alternative ma devono essere entrambe presenti considerazione; sempre nel lungo
periodo le due ottiche coincidono. Nel breve periodo invece può accadere il contrario; ciò accade perché
nel lungo periodo la nostra capacità di stime è minore il rischio di commettere errori è maggiore.
Analisi Differenziale  nell'analisi che svolgeremo (cioè per vedere se progetto genera valore) terremo in
considerazione solo i costi e il cashflow che verranno generati dal progetto. Esempi di costi non
differenziali: -costi affondati (già eseguiti prima del progetto) -costi non evitabili
NCF = Incoming CF – Outgoing CF
Pay Back Time  è il momento temporale nel quale il NCF di progetto copre i costi iniziali di progetto.
ΣPBT t=0 NCF(t) = 0 oppure CNCF(t)=0 con CNCF(i) = Σi t=0 NCF(t).
Problema: abbiamo bisogno di un metodo per attualizzare i futuri flussi di cassa in modo tale da poterli
comparare con i soldi spesi attualmente
Net Present Value  NPV(0) = ΣN t=0 NCF(t) / (1+r)^t cioè il valore attualizzato creato dal mio progetto
calcolato con i flussi di cassa netti.
Tasse  vengono calcolati in base all’EBIT e quindi sulla visione economica del progetto; sono un flusso di
cassa in uscita.
Cash Out (i) = Direct Cost (i) – AP (i) + AP (i-1) + Investimento (i) + Tasse (i)
Cash In (i) = Sales (i) (cioè fatture) – AR (i) + AR (i-1)
NCF (i) = Cash in (i) – Cash Out (i)
Calcolo tanti NCF, li sconto e poi li sommo! Ricavo l’NPV !!
Revenue (i) = Total Invoice*(Direct Cost (i) + Depreciation (i)) / (Total Direct Cost (i) + Investimento)
Σ Revenue (i) == Total Invoice !!!
EBIT (i) = Revenue (i) – Direct Cost (i) – Depreciation (i)
Tasse (i) = EBIT (i) * Tax Rate
EVA  viene calcolato al livello d'impresa nell'intero anno. Per calcolarlo e necessario conoscere il conto
economico aziendale dell'anno (cioè i costi e ricavi annuali) e lo stato patrimoniale cioè l’attivo (che
comprende tutte le risorse dell'impresa, i beni immobili, il capitale liquido e i crediti commerciali) e il
passivo (i soldi impiegati dagli azionisti e i debiti commerciali). Per calcolare l’EVA del progetto ha bisogno
del conto economico di progetto (cioè la contabilità) e lo stato patrimoniale di progetto. Quest'ultimo viene
creato partendo da quell'aziendale includendo tutti gli assi sette che il progetto utilizza. Tutti questi
parametri mi servono per calcolare il Net Invested Capital (NIC). Il NIC sarà dato dalla somma del Net
Working Capital (NWC) e dai Fixed Asset (FA). Il NWC sarà costituito dal WIP (work in progress) + Inventory
+ AR – AP. Il WACC viene calcolato in base al passivo di stato patrimoniale.
ΔWIP (i) = Revenue (i) – Sales (i)
WIP (i) = WIP (i-1) + ΔWIP (i-1)
NWC (i) = WIP (i) + AR (i-1) – AP (i-1)
NIC (i) = NWC (i) + FA (i)
Se investo all’anno 1  FA(2)=Invest FA(3)=FA(2) - 1 quota ammort FA(4)=FA(3) – 1 quota ammort
EVA (i) = EBIT (i) * (1 - TAX Rate) – NIC (i) * WACC
Calcolo tanti EVA, li sconto e poi li sommo! NPV ed EVA devono venire uguali a fine progetto!!!!
Come miglioro l’EBIT???
1)Riducendo i Costi 2) Aumentando l’efficienza 3) Aumento i Revenue
Come riduco il NIC???
1) Ottenendo migliori condizioni di pagamento dai fornitori e dai clienti
2) Applicando ritardi senza rischio ad attività molto dispendiose
BID / NO BID
Forme contrattuali:
A) Lump Sum  il contratto contiene un prezzo tutto compreso (cioè anche servizi ulteriori). Tutti i rischi
sono concentrati sull'azienda perché è necessario stare dentro al prezzo comunicato. Alti guadagni però.
B) Unit Price  tutti gli output hanno lo stesso prezzo oppure se il cliente acquista più di un tot di output il
prezzo diminuisce
C) Cost Plus Fee  il cliente paga ogni fattura emessa dall'azienda e quindi deve monitorare con un sistema
di controllo contabile l'andamento del progetto al fine di pagare il valore corretto. Al termine del progetto
viene riconosciuto un bonus all'azienda (Fee).
Dal caso A) verso quello C) il rischio si sposta dall'azienda verso il cliente.
Il caso C) tratti tipico dei casi nei quali cliente considera nulla la possibilità di variazione di costo tra quello
preventivato e quello finale. Il caso A) invece sarà quello nel quale il cliente considera alta la probabilità di
variazione di costo e quindi decide di allocare tutto il rischio sull'azienda; in caso di variazioni di costo
questo verrà scalato dal profitto dell'azienda.