Gestione dei grandi progetti di ingegneria: Il project management in azione 8880083511, 9788880083511

Citation preview

Franco Caron GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA It project management in azione

L isedi

41 isedi www.utetuniversita.it

Proprieta letteraria riservata / © 2009 De Agostini Scuola SpA - Novara 1° edizione: aprile 2009 Printed in Italy

Tutti i diritti riservati. Nessuna parte del materiale protetto da questo copyright potrà essere riprodotta in alcuna forma senza l’autorizzazione scritta dell'Editore. Fotocopie per uso personale del lettore possono essere effettuate nei limiti del 15% di ciascun volume/fascicolo di periodico dietro pagamento alla SIAE del compenso previsto dallart. 68, comma 4, della legge 22 aprile 1941 n. 633.

Le riproduzioni ad uso differente da quello personale potranno avvenire, per un numero di pagine non superiore al 15% del presente volume/fascicolo, solo a seguito di specifica autorizzazione rilasciata da AIDRO — Corso di Porta Romana 108 — 20122 Milano — e-mail segreteria @ aidro.org BIBL.

DELLE

INGEGNERIE

Stampa: Stampatre — Torino

POLITECNICO DID

Ristampe:

0

Anno:

2009

1

2 2010

3

4 2011

5

6

7

2012

8 2013

9

658.404 CAR

ACL

2041

GES

001G

MILANO

Indice

VII

I

Introduzione Le polarità del Project Management

Capitolo 1 Progetto e Project Management

1.1 Il progetto, p. 1 — 1.2 Gli attori del progetto, p. 4— 1.3 Il Project Management

e i suoi processi, p. 6 — 1.4 I parametri gestionali del progetto, p. 8 — 1.5 Criteri di successo, p. 10 — 1.6 Organizzazione del progetto, p. 10 — 1.7 Il ciclo di vita del

progetto, p. 11

15

Capitolo 2 Il ciclo di vita del progetto nel settore engineering & contracting

2.1 Introduzione, p. 15 — 2.2 L'acquisizione del contratto, p. 16 — 2.3 Il contratto, p. 23 — 2.4 La realizzazione del progetto, p. 29

31

Capitolo 3 Ingegneria 3.1 La fase di Ingegneria, p. 31 — 3.2 Ingegneria di base, p. 33 — 3.3 Ingegneria di dettaglio, p. 35 — 3.4 Project Engineering, p. 39

43

Capitolo 4 Approvvigionamento e gestione dei materiali 4.1 Introduzione, p. 43 — 4.2 Approvvigionamento, p. 44 — 4.3 Gestione dei materiali, p. 47

50

Capitolo 5 Costruzione e montaggio

5.1 Introduzione, p. 50 — 5.2 La programmazione delle attività di costruzione e montaggio, p. 51 — 5.3 La durata delle attività di costruzione e montaggio, p. 56

61

Capitolo 6 Il Progetto nel settore engineering & contracting 6.1 Introduzione, p. 61 — 6.2 Un caso — Realizzazione di un impianto di processo, p. 61 — 6.3 Caratteristiche del progetto, p. 65 — 6.4 Gli approcci gestionali, p. 71

74

Capitolo 7 Project start-up

7.4 Introduzione, p. 74 — 7.2 Architettura del progetto, p. 76 — 7.3 Il team di pro-

getto, p. 78 — 7.4 Il contesto organizzativo del progetto, p. 79 — 7.5 La struttura a

matrice, p. 82 — 7.6 Il portafoglio progetti, p. 84 86

Capitolo 8 La pianificazione e il controllo del progetto 8.1 Introduzione, p. 86 — 8.2 La pianificazione operativa del progetto, p. 87 — 8.3 I modelli del progetto, p. 92 — 8.4 Il controllo del progetto, p. 97 — 8.5 La qualità del progetto, p. 99

VI

INDICE

103

Capitolo 9 Work Breakdown Structure 9.1 Introduzione, p. 103 — 9.2 Le logiche di disaggregazione, p. 104 — 9.3 La WBS di progetto, p. 108 — 9.4 La WBS nelle società di Engineering e Contracting, p. 113 — 9.5 La standardizzazione della WBS, p. 115 - 9.6 WBS e pianificazione/controllo del progetto, p. 117

119

Capitolo 10 Avanzamento del progetto

10.1 Introduzione, p. 119 — 10.2 Lavanzamento fisico dei processi di costruzio-

ne/montaggio, p. 121 — 10.3 L’avanzamento fisico dei processi di ingegneria, p. 123 — 10.4 Vavanzamento fisico dell’intero progetto, p. 125 — 10.5 I diagrammi spazio-tempo, p. 125 — 10.3 Le curve ad S, p. 127 136

Capitolo 11 La programmazione temporale

11.1 Introduzione, p. 136 — 11.2 Il diagramma di Gantt, p. 137 - 11.3 Le tecniche reticolari, p. 139 — 11.4 Il calcolo delle date «al più presto» e «al più tardi», p. 143 — 11.5 Il Diagramma di Precedenza (Precedence Diagram), p. 149 — 11.6 CPM-costi, p. 154 — 11.7 Le tecniche reticolari come strumento di controllo, p. 156 — 11.8 Critical Chain, p. 158

162

Capitolo 12 La gestione delle risorse 12.1 Introduzione, p. 162 — 12.2.La gestione delle risorse di progetto, p. 165 — 12.3 Programmazione a capacità finita, p. 169 — 12.4 Regole di priorità, p. 170

175

Capitolo 13 La baseline dei costi l 13.1 Introduzione, p. 175 — 13.2 L'articolazione del progetto in voci di controllo, p. 178 — 13.3 La classificazione dei costi di progetto, p. 179 — 13.4 La stima dei costi, p. 181 — 13.5 La baseline dei costi di progetto, p. 187

191

Capitolo 14 Il controllo economico—finanziario del progetto 14.1 Introduzione, p. 191 — 14.2 Farned Value Management System, p. 193 — 14.3 La stima a finire, p. 201 — 14.4 Il controllo del cash flow di progetto, p. 208 — 14.5 La valutazione dei risultati economico—finanziari del progetto, p. 210

213

Capitolo 15 Gestione dei rischi di progetto

15.1 Introduzione, p. 213 — 15.2 La gestione dei rischi di progetto, p. 216 — 15.3 La dinamica del rischio, p. 223 — 15.4 I processi di analisi e gestione dei rischi di progetto, p. 225 — 15.5 La gestione degli stakeholder, p. 241

244

Capitolo 16 L'analisi probabilistica del progetto 16.1 Introduzione, p. 244 — 16.2 Le variabili di input, p. 246 — 16.3 L'analisi di «fattibilità» nella fase di montaggio, p. 251 — 16.4 Albero degli eventi, p. 257 — 16.5 La stima della contingency, p. 263 — 16.6 Il rischio temporale, p. 267 — 16.7 PERT (Project Evalutation and Review Technique), p. 273 — 16.8 Simulazione, p. 276

283

Bibliografia

introduzione

Le polarità del Project Management

La gestione di grandi progetti Questo testo riguarda la gestione di grandi progetti — usando un linguaggio ormai diffuso a livello internazionale potremmo parlare di Large Engineering

Projects — cioè di progetti riguardanti la realizzazione di opere complesse e di grandi dimensioni quali impianti industriali, infrastrutture civili, sistemi di comunicazione ecc. Nel testo si farà frequentemente riferimento al caso delle società di engineering & contracting, società cioè la cui attività consiste sostan-

zialmente nella realizzazione di grandi progetti per clienti esterni. Già questa prima delimitazione del campo d’interesse evidenzia una prima

_ «polarità» caratteristica del Project Management, analoga ad altre che incon-

treremo più avanti. Si tratta della polarità processi operativi/processi gestionali. Nell'ambito del progetto troviamo cioè sia processi operativi, legati all’avanza-

mento del progetto, sia processi gestionali legati al coordinamento del progetto. Nel caso del settore engineering & contracting i tipici processi operativi

comprendono: la progettazione (Engineering) avente come output la documen-

tazione tecnica necessaria a descrivere esaurientemente il sistema da realizzare, l’approvvigionamento (Procurement) avente come output l'emissione degli

‘ ordini e la messa a disposizione dei materiali necessari per la realizzazione del sistema, il montaggio (Construction) avente come output l’installazione e il collegamento dei componenti del sistema e infine l'avviamento (Commissioning) avente come output la messa in funzione del sistema che costituisce il ri-

sultato del progetto. I processi gestionali, riguardanti fondamentalmente la pianificazione e il controllo del progetto, consentono lo sviluppo del progetto fino al consegui-

mento degli obiettivi finali, rispettando i vincoli assegnati in termini di tempi, costi e qualità.

Mentre i processi operativi sono caratteristici del settore industriale cui il

progetto appartiene, i processi gestionali presentano invece caratteristiche di

ampia generalità in quanto applicabili ai settori più disparati, dalla realizzazio-

VIII

INTRODUZIONE

ne di infrastrutture, allo sviluppo di software e all’innovazione tecnologica. Sono stati sviluppati diversi tentativi di standardizzare i processi di Project Mana-

gement, tra cui per esempio «The Guide to Project Management Body of

Knowledge» sviluppato dal Project Management Institute, cui nel seguito fare-

mo frequentemente riferimento.

Una precisazione terminologica Per progetto intendiamo — nell’accezione anglosassone di «project» — non solo la fase di progettazione ma l’insieme delle fasi operative necessarie per arrivare a ottenere il completamento di un’opera prefissata; per esempio nel settore engineering & contracting il passaggio da prato verde a impianto funzio-

nante richiede come si è visto una serie tipica di fasi operative (progettazione,

approvvigionamento, montaggio, avviamento, collaudo) che costituiscono il progetto. Il termine italiano di progetto può prestarsi a qualche ambiguità in

quanto per progetto si può intendere il processo di progettazione o il risultato di tale processo, cioè la documentazione tecnica prodotta, mentre in inglese la distinzione è netta, in quanto i due termini di project e design hanno significa-

ti chiaramente distinti. Per fare un esempio di natura impiantistica la fase di «design» relativa al layout di una unità produttiva di tipo manifatturiero ri-

guarda la determinazione della configurazione planimetrica più appropriata in termini di sistemazione dei reparti nell’area disponibile tenendo conto del fabbisogno di area per ciascun reparto e dei flussi di materiali fra di essi, mentre ovviamente il progetto di realizzazione o modifica di un layout comprende operazioni di smontaggio, trasporto e montaggio dei mezzi di produzione.

Processi ripetitivi e processi non ripetitivi La definizione stessa di progetto s’inquadra nella «polarità» processi ripetitivi/processi non ripetitivi. Il Project Management riguarda infatti la gestione di processi operativi non ripetitivi. Si tratta quindi di processi che hanno co-

me contenuto un cambiamento e quindi introducono necessariamente conte-

nuti innovativi. Nella vasta area dei processi operativi, che coinvolge sia la

produzione di beni che di servizi, possiamo infatti distinguere due grandi

aree: l’area dei processi ripetitivi e l’area dei processi non ripetitivi (o progetti). Nel primo caso possiamo pensare a sistemi manifatturieri e distributivi

di beni di largo consumo, attraversati da flussi ripetitivi di operazioni e materiali. Sistemi di questo tipo, pensiamo per esempio a una linea di assemblaggio di elettrodomestici, presuppongono un elevato grado di standardizzazione sia dei prodotti che dei processi di produzione. Nel secondo caso possia-

INTRODUZIONE

IX

mo invece pensare alla realizzazione di una centrale termoelettrica, con inevitabili aspetti non ripetitivi sia del prodotto che del processo, dovuti per

esempio all’innovazione tecnologica, alle richieste da parte del cliente, all’a-

rea geografica di costruzione ecc. L'area dei settori produttivi operanti per «progetti» — cioè per processi produttivi non ripetitivi — appare molto ampia, certamente non limitata al settore

dell’engineering & contracting, cui peraltro faremo frequentemente riferi-

mento. Occorre per esempio considerare anche tutto il settore della produzione manifatturiera su commessa che di fatto si trova a operare per progetti. Tuttavia anche settori tradizionalmente considerati come caratterizzati da processi produttivi ripetitivi, quali la produzione manifatturiera di serie, risultano sempre più interessati da progetti, riguardanti per esempio lo sviluppo di nuo-

vi prodotti, processi, impianti ecc. Fattori quali l’elevato tasso di innovazione

tecnologica, la criticità del fattore tempo nella introduzione sul mercato dell’innovazione e la crescente difficoltà a fare riferimento a esperienze pregres-

se spingono ovviamente verso un’espansione dell’area interessata dal fenome-

no progetto.

Si potrebbe concludere che qualsiasi realtà produttiva sia caratterizzata, ovviamente con pesi diversi, dalla compresenza di processi ripetitivi e non ripetitivi, tra loro interdipendenti; si pensi per esempio alla gestione del trasporto pubblico locale in aree fortemente urbanizzate che prevede da una parte la fornitura «ripetitiva» del servizio con i necessari requisiti di regolarità e affidabilità e dall’altra la compresenza di progetti riguardanti il progressivo rinnovo del parco rotabile — in modo da garantire prefissati livelli di età media del parco

stesso — con le ovvie ricadute sulla gestione della manutenzione, delle parti di

ricambio, della formazione del personale ecc. L'area dei processi ripetitivi riguarda in generale lo stato stazionario del sistema produttivo, l’area dei processi non ripetitivi riguarda lo stato transitorio in particolare quello iniziale,

che porta il sistema produttivo nella fase di funzionamento.

Qualche cenno di storia In generale per comprendere un fenomeno che interessa il presente è necessario ripercorrerne la storia. Il progetto è un fenomeno che caratterizza la storia

dell’uomo fin dalle sue origini. Se risaliamo nel passato fino all’impero roma-

no, all'impero egiziano e oltre, i resti archeologici ancora visibili confermano

la dimensione e la complessità dei progetti in cui l’uomo si è espresso, e quindi

lo sviluppo dell’ingegneria industriale che tali progetti ha reso Se il fenomeno progetto rappresenta il problema di cui Project Management rappresenta il tentativo di risposta. Ci mente alla particolare versione che il Project Management ha

possibile. ci occupiamo, il riferiamo ovviaassunto in questi

X

INTRODUZIONE

ultimi decenni, soprattutto a partire dalla II Guerra Mondiale, periodo segnato da un intenso sviluppo tecnologico. Utilizzare il Project Management significa scommettere sul fatto che impie-

gando concetti, metodologie e tecniche sviluppate nel suo ambito aumenta la

probabilità che il progetto possa essere completato con successo. La nascita del moderno Project Management può essere datata attorno agli anni Quaranta del secolo scorso, durante la seconda guerra mondiale, con il

Progetto Manhattan, che prevede l’esteso e formale impiego di tecniche gestionali e organizzative di Project Management, quali «Work Breakdown Structure»

e «Organisation Breakdown Structure», nonchè la definizione di dettagliati pro-

grammi temporali e finanziari. Negli anni Cinquanta, caratterizzati dalla frene-

tica ricostruzione post bellica, si sviluppano e si affermano le tecniche di programmazione reticolare, quali «Critical Path Method», «Program Evaluation Review Technique» e «Precedence Diagramming». Nel 1959 viene pubblicato su Harvard Business Review un articolo di G.O. Gaddis dal titolo The Project Manager. In questo periodo le società di engineering & contracting svolgono di fatto un ruolo pionieristico nella diffusione e nello sviluppo del Project Management. Gli anni Sessanta vedono da una parte lo sviluppo di nuove metodologie integrate di pianificazione e controllo dei progetti in termini di tempo e costo («Cost Schedule Control System») e dall’altra un approfondimento delle diverse opzioni organizzative per la gestione dei progetti (strutture a matrice, a task force ecc.). Nascono, sempre in questo periodo, le prime associazioni profes-

sionali di project manager, tra cui la più importante è il Project Management Institute negli Stati Uniti. Negli anni Settanta l’attenzione si focalizza sugli aspetti

strategici dei progetti, con particolare riferimento al «contesto» di progetto, sia esso di tipo sociale, politico, economico, culturale ecc. Gli anni Ottanta registra-

no l’espansione del Project Management al di fuori del tradizionale settore del-

l’engineering & contracting verso altri settori industriali di tipo manifatturiero o

del terziario. Sul piano metodologico si afferma l’enfasi sugli aspetti di «Qua-

lity Assurance» nella gestione dei progetti. Si affermano le prime esperienze di

contratti BOOT (Build Own Operate Transfer) e di Project Finance. Appare la prima versione del «Project Management Body of Knowledge» elaborata dal PMI.

Si sviluppano inoltre in modo intensivo le applicazioni software per il

Project Management. Gli anni Novanta vedono da una parte l’enfasi sul re-engi-

neering dei processi aziendali in modo da migliorare la competitività e dall’altra lo sviluppo delle applicazioni telematiche nella trasmissione ed elaborazione

delle informazioni. Una crescente attenzione riceve l’analisi e la gestione dei rischi di progetto come modalità per ottenere un più efficace controllo dei tradizionali parametri di performance dei progetti in termini di tempi, costi e caratteristiche tecniche del prodotto finale.

Siamo così arrivati al presente, alle tendenze cioè che caratterizzano il

Project Management nel nuovo millennio.

_

INTRODUZIONE

XI

Project Management Body of Knowledge Nell’arco dell’ultimo decennio svariati tentativi sono stati condotti per for-

malizzare e standardizzare gli aspetti professionali del project management in termini di competenze,

capacità e attitudini necessarie per operare nel-

l’ambito dei progetti, in modo da arrivare alla formulazione dei criteri per la certificazione professionale degli specialisti di project management. Tra le diverse associazioni professionali che si sono mosse in questa direzione (Project Management Institute, International Project Management Association, Australian Institute of Project Management, Association for Project Management England) sicuramente il PMI con il Project Management Body Of Knowledge (PMBoK) e il relativo processo di certificazione professiona-

le tende di fatto a definire uno standard globale a livello mondiale. È questo il motivo per cui nello sviluppo del testo faremo riferimento al PMBoK per

la definizione dei principali processi gestionali che intervengono nella ge-

stione dei progetti.

Occorre sottolineare che la cultura del Project Management non riguarda esclusivamente il ruolo del Project Manager (o di chi comunque svolge una funzione di governo del progetto nell’ambito del Project Team) ma coinvol-

ge tutti coloro che a vario titolo si trovino a operare nell’ambito di un progetto. Qualsiasi apporto specialistico venga fornito all’avanzamento di un gene-

rico progetto richiede necessariamente un adattamento alle logiche intrinseche del progetto in modo da contribuire all’ottenimento del risultato atteso. È l’integrazione dei diversi punti di vista specialistici, oltre ai vincoli generali di tempo, costo e qualità, che condiziona le modalità di esecuzione di ogni processo operativo. Non necessariamente l’ottimizzazione specialistica corrisponde infatti all’ottimizzazione globale. Per esempio la riduzione delle

ore di ingegneria (e dei relativi costi che rappresentano circa il 10% dei costi

generali di un progetto impiantistico) può tradursi nella conseguente riduzione del numero di offerte considerate nella fase di approvvigionamento e

quindi nella perdita di significative opportunità di abbattere i costi di acqui-

sto dei materiali (che possono rappresentare anche il 40% del costo globale di progetto). La visione del Project Management basata su una serie di «polarità» carat-

teristiche che viene di seguito presentata, non è altro in fondo che un modo di esplicitare i contenuti fondamentali della professionalità del project mana-

ger e più in generale di chi sia professionalmente coinvolto in un progetto. Le nuove polarità che introdurremo si vanno ad aggiungere a quelle che abbiamo già individuato: processi ripetitivi/ non ripetitivi, processi operativi/gestionali.

XII

INTRODUZIONE

Prima polarità: objectives vs stakeholders La gestione del progetto richiede una doppia focalizzazione: da una parte gli obiettivi del progetto e dall’altra gli attori del progetto. Potremmo dire che il

successo del progetto dipende in modo rilevante dalla capacità di mantenere una costante attenzione a questa duplicità di aspetti. Sul primo versante restia-

mo nell’ambito delle tradizionali tecniche di pianificazione e controllo del pro-

_ getto e quindi dei processi gestionali relativi a contenuti, tempi, costi e qualita

del progetto. Sul secondo versante l’attenzione si sposta sugli attori del proget-

to, che non sono soltanto cliente, contractor e fornitori ma possono compren-

dere partners, enti pubblici, gruppi sociali ecc. Ogni attore può esprimere per

quanto riguarda 11 progetto interessi diversi, una diversa capacità di influenza e un atteggiamento più o meno favorevole. Di qui l’importanza di ogni azione

volta a coinvolgere, informare, influenzare il comportamento dei singoli attori

tenendo conto delle aspettative di ciascuno. Possiamo parlare di una vera e pro-

pria gestione «politica» del progetto. Si tratta cioè di prevenire rischi che pos-

sono provenire dagli attori del progetto minacciandone il successo. La gestione dei due aspetti, contenuti e attori di progetto, presenta ovviamente delle inter-

dipendenze: nel caso dei grandi progetti non è infrequente una significativa riconfigurazione del progetto («project shaping») in funzione delle esigenze

espresse dagli attori il cui consenso sia necessario al successo del progetto. Le relazioni fra gli attori coinvolti nel progetto possono essere di diversa natura, in

quanto ben difficilmente progetti di rilevanti dimensioni possono essere realizzati nell’ambito di una singola organizzazione, affidando il coordinamento del progetto ai meccanismi organizzativi interni. Il progetto vive generalmente in un contesto di tipo contrattuale: sono infatti dei contratti che regolano i rapporti fra cliente, contractor, partners, fornitori. A questo si aggiunge il contesto

istituzionale, in quanto molteplici sono gli enti di natura pubblica che interven-

gono a vario titolo nel progetto, quantomeno per tutti gli aspetti autorizzativi riguardanti la realizzazione dell’opera pianificata. Infine esiste un problema di consenso alla realizzazione dell’opera da parte di tutti i gruppi e le realtà socia-

li in qualche modo interessate al progetto, per esempio da parte di tutti coloro che si trovano a vivere in prossimità dell’opera da realizzare.

Seconda polarità: «hard» skills vs «soft» skills Se abbandoniamo la visione «macro» del progetto riguardante gli stakeholder e passiamo a una visione «micro» possiamo mettere a fuoco il Project Team, il gruppo cioè composto dai diversi specialisti coordinati dal project manager cui è affidata la conduzione del progetto. Si tratta di un gruppo in genere basato su

un modello di funzionamento organizzativo di tipo «organico», tale cioè da ri-

INTRODUZIONE

— XIII

chiedere una costante interazione tra i diversi ruoli coinvolti. Al Project Team

sono affidati due compiti molto importanti: da una parte garantire l’integrazione delle diverse competenze che intervengono nel progetto e dall’altra la necessaria capacità di flessibile adattamento del progetto alle sollecitazioni pro-

venienti dall’ambiente interno ed esterno. Il funzionamento del Project Team fa emergere una nuova duplicità di aspetti del Project Management, entrambi

necessari al successo del progetto: da una parte le capacità gestionali e dall’altra le capacità relazionali. Sul primo versante troviamo la capacità di utilizzare le logiche, le metodologie e le tecniche necessarie per la pianificazione e il controllo del progetto, sull’altro le capacità di interagire in modo efficace con gli altri componenti del Project Team. A questo secondo versante appartengono capacità motivazionali, capacità di leadership, capacità negoziali, capacità di

gestire le dinamiche di gruppo ecc. Un progetto può fallire, e il caso non è infrequente, non tanto per limiti tecnici o gestionali quanto per l’assenza di effi-

cace interazione tra i membri del Project Team. Il progetto può raggiungere i suoi obiettivi soltanto attraverso il coinvolgimento attivo delle persone, in

quanto gli aspetti non ripetitivi del progetto non consentono il ricorso a meccanismi già collaudati. sO

Terza polarità: synthesis vs analysis | La gestione del progetto presenta un terzo tipo di polarità: quella tra una visione sintetica e una visione analitica del progetto. Anche in questo caso i due. aspetti devono essere contemporaneamente salvaguardati. Nel primo caso si tratta per esempio di ricondurre la valutazione di performance del progetto ad alcuni indicatori estremamente sintetici. È quanto capita per esempio quando a un generico time now ci si propone di ricondurre la valutazione di avanzamento del progetto a un unico valore percentuale. Fatti estremamente numerosi e di| versificati vengono ricondotti cioè a unico parametro quantitativo. Nel secondo caso occorre mettere a fuoco gli aspetti di dettaglio del progetto; si consideri

per esempio la quantità di materiali che interviene nella realizzazione di un impianto di processo e la corrispondente quantità di documenti (richieste di acqui-

sto, richieste di offerta, ordini ecc.) che ne consente l’approvvigionamento: ognuno di questi elementi di dettaglio deve essere singolarmente gestito se si. vuole garantire il rispetto degli appuntamenti produttivi che consentono la realizzazione del progetto. La corretta gestione del progetto richiede che la visione «complessiva» del progetto — basata su pochi indicatori di performance — e la visione «di dettaglio» dei singoli elementi del progetto — materiali, documenti,

attività ecc. — siano tra loro congruenti, che cioè la miriade di eventi che costi-

tuiscono il progetto vengano adeguatamente considerati nella valutazione d’in-

sieme.

XIV

INTRODUZIONE

Quarta polarità: deterministic vs stochastic Tradizionalmente la pianificazione del progetto utilizza un approccio deterministico, basato cioè su una stima puntuale dei parametri di tempo, costo e prestazione tecnica che caratterizzano il progetto, quale per esempio la durata del-

le singole attività previste. È questa la condizione fondamentale per fissare al-

cuni «milestone» di riferimento che identifichino le scadenze entro cui raggiungere specifici obiettivi. È tuttavia fin troppo scontato sottolineare il grado

di incertezza che caratterizza il progetto, soprattutto nella sua fase iniziale, sia

per la sua non ripetitività sia per il fatto che riero di imprevisti. L'esito di tale incertezza di una variabilità dei parametri caratteristici zarsi di possibili eventi rilevanti, in entrambi

esso riguarda un futuro spesso fopuò essere descritto sia in termini del progetto sia come materializi casi con effetti negativi o positi-

vi sul progetto. Accanto alla visione deterministica del progetto occorre pertanto anche una visione diversa che tenga conto dell’incertezza intrinseca del

progetto, per esempio attraverso una descrizione probabilistica della variabilità dei parametri e del verificarsi di possibili eventi rilevanti per il successo del

progetto. In questo modo è possibile da una del progetto più «robusta» e dall’altra gestire progetto, sia prevedendo opportune riserve-A costi e prestazioni tecniche sia pianificando

parte/ottenere una pianificazione infModo proattivo l’incertezza di copertura di variazioni di tempi, opportune azioni di mitigazione

dei possibili fenomeni indesiderati. Per quanto possa essere efficace questo tentativo di mettere a fuoco l’incer- tezza di progetto è evidentemente impossibile identificare seppur in termini

probabilistici tutti i possibili eventi che possono condizionare lo sviluppo del progetto. Un aspetto di imprevedibilità ovviamente resta. Occorre quindi met-

tere in conto la capacità di chi gestisce il progetto di reagire agli imprevisti che possono verificarsi. Questa capacità di reazione può andare da un adattamento

del piano iniziale, a una ripianificazione sostanziale fino a una revisione glo-

bale dell’architettura di progetto.

Quinta polarità: deliverables vs knowledge Se da una parte il progetto può essere visto come un sistema che riceve in input delle risorse per fornire in output dei «deliverables», dall’altra esso può essere visto come un sistema che riceve in input diverse conoscenze specialistiche, le integra e ne genera di nuove in output, sia a livello individuale che di Project Team che di organizzazione nel suo insieme. Quello che appare particolarmen-

te critico nel caso dei progetti è la capacità di riutilizzare ai fini della pianifica-

zione dei nuovi progetti conoscenze ed esperienze accumulate nei progetti pre-

cedentemente completati. Diventa pertanto fondamentale la capacità di racco-

INTRODUZIONE

XV

gliere, organizzare, mantenere e condividere dati e «lezioni imparate» prove-

nienti dai progetti passati. L'approccio a un nuovo progetto richiede infatti sia l’acquisizione di nuove conoscenze all’esterno sia il riutilizzo di conoscenze accumulate all’interno, sia come conoscenze «esplicite» contenute nei sistemi gestionali e nei database che «tacite», legate cioè alle esperienze maturate dalle singole persone.

Project Management: recenti tendenze Il Project Management costituisce una disciplina attualmente in fase di evoluzione. Almeno tre sono le linee di sviluppo che occorre citare: ° l'estensione lungo il ciclo di vita del progetto; * l’estensione al livello strategico della gestione aziendale;

* il coinvolgimento di un numero crescente di stakeholder.

Per quanto riguarda il primo punto, se facciamo riferimento al settore dell’engineering & contracting, già da tempo si è superata una visione del ciclo di vita del progetto limitata alla fase di «project execution» — cioè alla fase realizzativa vera e propria che peraltro costituisce l’oggetto dei processi di standardizzazione finora intrapresi a livello internazionale tra cui per esempio il PMI BoK — per comprendere anche la fase di proposal management, cioè

tutta la fase preliminare che riguarda la preparazione, la presentazione e la ne-

goziazione dell’offerta per acquisizione del contratto relativo all'esecuzione del progetto. Tendenza recente è l’estensione della gestione di progetto alla fa-

se successiva a quella di «project execution», alla fase cioè di «operations» in

cui ci si aspetta di ottenere i benefici attesi da quanto il progetto ha realizzato. Questa visione globale del ciclo di vita del progetto si rende particolarmente necessaria in tutti i casi di project finance: è proprio dalla fase di operations che ci si aspettano gli incassi necessari a ripagare gli investimenti effettuati in fase realizzativa (per esempio i pedaggi degli utenti consentono di ripagare gli

investimenti per la costruzione di un’autostrada). Questa visione del progetto, sposta l’attenzione dai deliverable del progetto ai benefici che ne derivano per

il cliente o per i clienti del cliente (per esempio dalla realizzazione di un edificio scolastico ai servizi scolastici che esso consente di offrire al territorio circostante). Il secondo punto riguarda l’estensione del project management dalla gestione del singolo progetto, alla gestione di programmi di progetti tra loro correlati, alla gestione dell’intero portafoglio progetti fino ad arrivare alla strategia aziendale. Questa visione non solo consente di mettere a fuoco le interdipendenze operative e finanziarie tra i progetti ma anche di bilanciare il portafoglio in ter-

XVI

INTRODUZIONE

‘ mini di orientamenti strategici, redditività e rischiosità. Il terzo punto estende il

numero e la tipologia degli stakeholder coinvolti a vario titolo nel progetto, met-

tendo a fuoco le aspettative dei diversi stakeholder la cui soddisfazione è condi-

zione del successo del progetto. Struttura del testo

Questo testo non vuole essere una rassegna enciclopedica di best practice. Per questo si rimanda ai vari standard professionali in particolare al Project Management Institute Body of Knowledge, cui si farà frequentemente riferimento

nel testo. Peraltro una rassegna di best practice sarebbe soggetta a un elevato ri-

schio di obsolescenza data la rapida evoluzione attualmente in corso nella disciplina del Project Management. La disponibilità di strumenti gestionali anche sofisticati non garantisce il successo del progetto se non si è in grado di comprenderne la logica e di adattarli allo specifico contesto applicativo.

Lo scopo del testo è soprattutto didattico, basato su un approccio «back to basics», volto cioè a risalire al «nocciolo» della materia in modo da ricostruirne le

logiche fondamentali che mantengono la loro validità anche al mutare delle mode. Spetterà poi all’attività professionale trovare il giusto compromesso tra il rigore metodologico proposto dal testo e le caratteristiche specifiche dei singoli contesti applicativi, ben sapendo che rigore metodologico e flessibilità applicativa non sono assolutamente in contrasto ma anzi rappresentano i due elementi

basilari della professionalità di chi opera nel Project Management. Il primo capitolo introduce definizioni e caratteristiche fondamentali di Progetto e Project Management. I capitoli dal secondo al sesto sono dedicati all’analisi del ciclo di vita di un progetto tipico del settore engineering & contracting. Vengono messe a fuoco

innanzitutto le caratteristiche intrinseche del fenomeno progetto — cioè la natu-

ra del problema da affrontare — prima di trattare gli approcci gestionali svilup-

pati per rispondere al «problema» progetto. In particolare il secondo capitolo è dedicato alla fase di competitive bidding, cioè alle problematiche di preparazione, presentazione e negoziazione dell’offerta, legate all’acquisizione del contratto sulla base del quale verrà poi sviluppato il progetto. Si tratta a tutti gli effetti della fase di impostazione «strategica» del progetto, in cui trovare il miglior compromesso tra «valore» offerto al cliente e «vincoli» che ne deriveran-

no per la realizzazione del progetto. I capitoli terzo, quarto e quinto sono dedi-

cati alle fasi operative principali caratteristiche del progetto nel settore engineering & contracting: ingegneria, approvvigionamento e montaggio. Il sesto

capitolo riguarda la gestione integrata del progetto nella sua globalità. A partire dal settimo capitolo inizia la presentazione degli strumenti e delle

tecniche gestionali tipiche del Project Management, utilizzabili quindi in modo

INTRODUZIONE

XVII

generalizzato in tutti i settori applicativi. In particolare il settimo capitolo è dedicato alla fase di start-up del progetto, nella quale il Sistema di Project Management sviluppato a livello aziendale viene applicato e adattato al progetto nella sua fase di avvio. L’ottavo capitolo introduce le problematiche di pianificazione operativa del progetto: vengono introdotti i modelli fondamentali, quali la disaggregazione gerarchica, il reticolo e la curva ad S. I capitoli dal nono al quindicesimo trattano le diverse aree tematiche della pianificazione e controllo del progetto. Il nono capitolo è dedicato al contenuto del progetto («scope of work») in particolare alle tecniche di disaggregazione

gerarchica del progetto («project breakdown»). Il decimo capitolo è dedicato all’avanzamento «fisico» del progetto. L’undicesimo capitolo è dedicato alla programmazione temporale del progetto mediante strumenti quali le tecniche reticolari. Il dodicesimo capitolo è dedicato alla gestione delle risorse di progetto. Il tredicesimo capitolo è dedicato alla definizione della «baseline» dei costi di progetto. Il quattordicesimo capitolo è dedicato al controllo economico-finanziario del progetto, utilizzando il concetto di «earned value», fino ad

arrivare alla valutazione dei risultati conclusivi di progetto. Il quindicesimo capitolo è dedicato all’analisi e gestione dei rischi di progetto. Infine il sedicesimo capitolo introduce i metodi quantitativi che consentono l’analisi dell’incertezza del progetto.

EC.

GESTIONE

DEI GRANDI

PROGETTI DI INGEGNERIA

Capitolo 1

Progetto e Project Management

1.1

Il progetto

Sono estremamente diversificati i termini con cui normalmente ci si riferisce ai

progetti e ai relativi ambiti applicativi:

PROGETTO PROGRAMMA COMMESSA INIZIATIVA APPALTO

di di di di di di di

ricerca sviluppo prodoito investimento sviluppo processo sviluppo organizzativo sviluppo informatico manutenzione

In generale possiamo definire il progetto come un processo realizzativo non

ripetitivo. In letteratura sono ovviamente disponibili svariate definizioni di «progetto». Riportiamo in quanto emblematiche le definizioni date dal Project

Management Institute in corrispondenza di diverse edizioni del PMIBoK. Le definizioni date rispettivamente nel 1987 e nel 1992 possono essere così sintetizzate: il progetto è * * ° *

combinazione di risorse umane e non, riunite in una organizzazione temporanea, per raggiungere un obiettivo definito, con risorse limitate. (Project Management Institute, 1987)

° un processo temporaneo, * finalizzato alla produzione di una o più unità di un unico prodotto o servizio,

e le cui caratteristiche vengono elaborate progressivamente.

(Project Management Institute, 1992)

2

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

La definizione data nel 2004 introduce una drastica semplificazione e recita

testualmente: «A project is a temporary endeavor undertaken to create a unique product, service or result» (Project Management Institute, 2004). Quest'ultima definizione sottolinea due aspetti fondamentali: l’unicità e la temporaneità. Loutput del progetto può essere un prodotto fisico, un servizio 0

più in generale un risultato quale una trasformazione introdotta in una struttura organizzativa.

Può essere interessante tuttavia fare un passo indietro e confrontare le due precedenti definizioni. La differenza tra di esse evidenzia un approfondimento

intervenuto nel concetto di progetto. La seconda sottolinea infatti il fatto che le

caratteristiche del risultato del progetto vengono elaborate progressivamente

nel corso del progetto stesso. Potremmo dire che mentre nel caso dei processi ripetitivi prodotto e processo realizzativo devono essere analiticamente noti «a priori» , nel caso dei progetti tale conoscenza analitica costituisce di fatto il risultato «a posteriori» del progetto. Per esempio il progetto di un impianto chimico inizia con l’ingegneria di processo, cioè con la definizione delle diverse fasi di trasformazione che la materia prima deve subire per diventare prodotto finito. Su questa base vengo-

no definite le caratteristiche funzionali delle principali unità d’impianto, dato

che a ciascuna fase di trasformazione corrisponde in generale un’unità d’impianto. Vingegneria di dettaglio provvede successivamente a elaborare la progettazione dei componenti d’impianto, dei servizi ausiliari e della planimetria dell’impianto. Sulla base di tale documentazione tecnica si procede poi ad avviare i processi di approvvigionamento e montaggio, durante i quali ulteriori modifiche alla configurazione dell’impianto sono ancora possibili. Come si vede, sicuramente sono note fin dall’inizio le caratteristiche funzionali e prestazionali dell’impianto che si desidera ottenere, ma le caratteristiche costrutti-

ve vengono elaborate progressivamente in corso di progetto. A prescindere dalle definizioni utilizzate, che come si è visto possono essere

molto varie, le caratteristiche ricorrenti del «progetto» possono essere così sintetizzate: * e » *

obiettivi definiti; unicità (non ripetitività); elaborazione progressiva; temporaneità;

* integrazione multidisciplinare;

» disponibilità limitata di risorse; * incertezza.

Il concetto di obiettivi definiti implica, come si è già detto, una definizione

«a priori» dei bisogni che si intendono soddisfare, almeno in termini funziona-

PROGETTO

E PROJECT MANAGEMENT

3

li, mentre le soluzioni costruttive più appropriate verranno sviluppate nel corso

del progetto. Inoltre, date le caratteristiche di non ripetitività, il risultato del progetto deve presentare un contenuto almeno parzialmente innovativo. La pa-

rola temporaneità rimanda al fatto che il progetto è caratterizzato da un ciclo di

vita che prevede una fase di avvio e una fase di chiusura. La parola multidisci-

plinarietà rimanda invece alla complessità del progetto data la varietà degli ap-

porti, dei linguaggi, delle specializzazioni, delle estrazioni culturali che inter-

vengono e che devono trovare un terreno comune di integrazione. La disponi-

bilità limitata di risorse rimanda alle condizioni normali di gestione dei progetti in ambito industriale, dove qualsiasi contratto presuppone l’accettazione da parte del cliente di un’offerta impegnativa che stabilisce vincoli di tempo e costo per l’esecuzione del progetto. Infine, dato che il progetto prevede un contenuto innovativo da realizzare nel futuro, esso appare soggetto a un elevato gra-

do di incertezza. _ In sintesi possiamo affermare che mentre i processi ripetitivi riguardano lo stato stazionario dei sistemi produttivi, i progetti riguardano il transitorio ini-

ziale — quello cioè che porta alla loro realizzazione — ma anche ovviamente quello finale — che porta cioè al loro smantellamento. Dei processi non ripetitivi si occupa come abbiamo visto il Project Management. Nella Tab. 1.1 sono messe a confronto le caratteristiche principali dei due tipi di processi. La ripetitività costituisce ovviamente il prerequisito per la standardizzazione del pro-

dotto e del processo, nonché per il miglioramento incrementale di entrambi. La

possibilità di operare in condizioni stabili e prevedibili favorisce una modalità

di coordinamento basata sul rispetto di norme e procedure prefissate, secondo

un modello organizzativo tipicamente «meccanicistico». Nel caso dei progetti invece, date le caratteristiche di incertezza in cui ci si trova a operare, le modalità di coordinamento non possono basarsi che sulla interazione diretta degli attori coinvolti, i quali devono cooperare al fine di correggere gli eventuali sco-

stamenti dell’andamento del progetto rispetto al piano di realizzazione, secondo un modello organizzativo tipicamente «organico». Sulla base delle «lezioni imparate» dai progetti già conclusi il Sistema di Project Management, in quan-

to applicato ripetutamente a progetti dello stesso tipo, può essere oggetto di

miglioramento incrementale. Tab. 1.1

Processi ripetitivi e non ripetitivi (progetti)

Processi ripetitivi Standard

___

Prodotio/Processo predefiniti Modello «meccanicistico» Miglioramento incrementale del processo

Strutture permanenti

Processi non ripetitivi Non standard

_

Prodotto/Processo sviluppati in itinere Modello «organicistico» Miglioramento incrementale del sistema di gestione Strutture temporanee

4

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

I progetti possono essere suddivisi in: ° progetti interni; * progetti esterni (per la fornitura a terzi di prodotti/servizi). I primi corrispondono ai processi di innovazione interna che caratterizzano

in generale l’evoluzione aziendale. Tali progetti possono riguardare per esempio, nel settore manifatturiero: * ricerca e sviluppo di nuovi prodotti; * ingegnerizzazione di nuovi processi;

e * * *

installazione/modifica/ampliamento di impianti; progettazione/costruzione di nuove apparecchiature; revisione/espansione del layout; . progettazione/implementazione del sistema informativo;

* ristrutturazioni organizzative;

° ecc.

I secondi riguardano la fornitura a terzi di prodotti e/o servizi, come nel caso delle Società di engineering & contracting (che ovviamente sono anche soggette a progetti interni, quali l’introduzione di nuovi sistemi CAD per la progettazione degli impianti). |

1.2

Gli attori del progetto

Il progetto comporta la costituzione di una macro—rete temporanea di organiz-

zazioni e gruppi sociali che rappresentano gli attori («stakeholder») del proget-

to. Tali attori, caratterizzati ciascuno da obiettivi e vincoli propri, costituiscono

«il contesto» nel cui ambito si sviluppa il progetto e possono talvolta esercitare

un’influenza determinante sul successo del progetto stesso.

Nel settore dell’engineering & contracting le relazioni tra gli attori coinvolti nel progetto possono essere sinteticamente schematizzate come illustrato in Fig. 1.1. Tutti gli attori che svolgono un ruolo funzionale nell’ambito del pro-

getto, cioè legato al suo concreto avanzamento, sono in genere legati da rela-

zioni di tipo contrattuale. Istituzioni pubbliche e gruppi sociali possono influenzare il progetto in termini di iter autorizzativi e consenso necessari alla

realizzazione dell’opera. Si esaminano di seguito singolarmente i ruoli indicati in Fig. 1.1, al fine di evidenziarne le principali caratteristiche. Utilizzatore

E chi usufruirà dell’output del progetto. Dall’utilizzatore proviene, in maniera diretta o più spesso mediata attraverso la figura del committente, l’esigenza

PROGETTO

E PROJECT MANAGEMENT

Committente

5

Consulente

(Cliente)

del cliente

Licenziatario

Utilizzatore

Contractor

|

Fornitore

Normatori esterni lm

Fig. 1.1

Altri

Macro rete esterna degli attori del progetto

che — nei termini espressi dall’obiettivo esplicito del progetto — ci si propone di

soddisfare. La relazione esistente tra utilizzatore e committente varia molto a seconda dei casi. Si pensi al caso di commesse relative a opere pubbliche, nel quale il passaggio dalle esigenze dell’utilizzatore alla definizione degli obiettivi di progetto avviene attraverso vari livelli di intermediazione. Si fa in ogni caso riferimento all’utilizzatore per definire le condizioni operative che caratterizzeran-

no l’output del progetto nell’arco della sua vita utile.

Committente Il committente è colui che emette una richiesta di offerta per la realizzazione

del progetto. Al termine della gara, che coinvolge diversi potenziali contractor,

il committente assume la responsabilità della gestione del contratto stipulato con l’azienda che si è aggiudicata la commessa. Tale responsabilità, valida per l’intero «ciclo di vita» del progetto, qualifica il committente come interlocutore diretto dell’appaltatore («contractor») fino al completamento del progetto stesso.

Contractor

È l’azienda (o l’insieme di aziende) che, avendo vinto la gara, stipula con il committente il contratto di fornitura. Talvolta i progetti prevedono la coopera-

zione di imprese diverse, delle quali si mira a utilizzare sinergicamente le risor-

6

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

se e le specifiche esperienze. Le esigenze di coordinamento del progetto im-

pongono comunque di assegnare a uno dei partner la funzione di leader («main contractor»). Licenziatario

Il contenuto tecnologico del progetto, per esempio il brevetto del processo pro-

duttivo utilizzato, che il Committente o il Contractor giudicano conveniente adottare, può non essere patrimonio dei partecipanti al progetto. In tal caso si

devono avviare trattative con il proprietario della tecnologia e del relativo —

know-how, al fine di ottenere la necessaria licenza e di istituire eventuali rap-

porti di collaborazione in fase di acquisizione/realizzazione del progetto.

Fornitore È in generale il terzo presso cui vengono acquistati i materiali necessari all’esecuzione del progetto («vendor»). Può anche essere l’impresa cui vengono appaltati i lavori di costruzione/montaggio («sub contractor»). Normatori esterni î Gli enti normatori competenti, a vari livelli (locale, nazionale, internazionale)

e nei diversi ambiti geografici (località interessate dalla realizzazione del pro-

getto, sede dell’azienda appaltatrice ecc.) nelle materie inerenti il progetto rap-

presentano un riferimento determinante sia in fase di impostazione che di esecuzione del progetto. Si pensi per esempio ai possibili effetti del progetto in termini di salute dei lavoratori, sicurezza dell’impianto e impatto ambientale

(safety, health, environment).

Altri Le persone o gli enti esterni sui quali il progetto ha qualche rilevante ricaduta — per esempio la popolazione residente nell’area in cui viene realizzato l’impianto — sono potenziali attori del progetto stesso.

1.3

II Project Management e i suoi processi

Nell’ambito del progetto possiamo identificare tre tipi di processi: * processi operativi; * processi gestionali;

* processi organizzativi.

I primi riguardano l’avanzamento fisico del progetto, i secondi il coordinamento del progetto sulla base del piano di realizzazione e infine i terzi la ge-

PROGETTO

E PROJECT MANAGEMENT

7

stione delle risorse umane (selezione, formazione, definizione dei ruoli, carriere ecc.). Per esempio, nell’ambito dell’ engineering & contracting possiamo identificare i seguenti processi operativi:

* ingegneria (design);

° approvvigionamento (procurement); * costruzione/montaggio (construction); ° avviamento/collaudo (commissioning/test).

Per quanto riguarda i processi gestionali il Project Management Institute ha identificato 1 seguenti processi: *

start up;

e. planning;

e monitoring/executing; * control; ° close out.

L'esistenza di fasi pianificate di start up e close out documenta la natura

temporanea del progetto. Il processo di executing, che implica l’impiego delle risorse in funzione degli obiettivi di progetto, coinvolge il project manager in termini di autorizzazione all’impiego delle risorse ma riguarda fondamentalmente l’esecuzione dei processi operativi. Questi ultimi devono seguire la ba-

seline di progetto e rappresentano la fonte fondamentale di informazioni per il controllo del progetto. I processi gestionali rappresentano l’ossatura del Project Management. Ve-

diamo a questo riguardo le definizioni fondamentali date dal Project Manage-

ment Institute: «Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements» (Project

Management Institute, 2004); «Project Management is accomplished through

the application and integration of the project management processes of initiating, planning, executing, monitoring, controlling and closing» (Project Management Institute, 2004). La sequenza dei processi gestionali può essere applicata a ciascuna delle aree di conoscenza in cui si articola il Project Management: * Integration Management; * Scope Management; ° Quality Management; e Time Management; ° Cost Management;

8

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

* Risk Management; * Human Resource Management; e Communication Management; Contract & Procurement Management.

Se consideriamo per esempio l’area dei costi di progetto, avremo i seguenti processi gestionali: predisposizione del sistema di gestione dei costi, stima dei costi di progetto, formulazione della baseline dei costi, controllo dei costi, chiu-

sura del sistema di gestione dei costi. Mediante l’incrocio tra processi gestionali

e aree di conoscenza, il PMI BoK rappresenta pertanto una mappa dei principali

processi gestionali che intervengono nell’ambito di un generico progetto. La modalità con cui, nell’ambito di un’azienda operante per progetti, vengono condotti i diversi processi di project management è formalizzata nel Sistema di Project Management: «The Project Management System is the set of po-

licies, processes, tools, techniques, methodologies, resources and procedures used to manage a project» (Project Management Institute, 2004). Mentre il Sistema di Project Management appartiene all’azienda (e quindi è progressivamente migliorabile man mano che 1 progetti vengono completati), il Piano di Gestione del Progetto riguarda uno specifico progetto e descrive le modalità con cui verranno condotti i diversi processi nell’ambito del progetto stesso.

Come afferma il PMI Bok: «The Project Management Plan describes how the

Project Management System will be applied to a particular project. The Project

Management Plan integrates all subsidiary plans» (Project Management Institute, 2004).

1.4

parametri gestionali del progetto

Tradizionalmente i parametri gestionali caratteristici del progetto sono indivi-

duati nella classica triade: tempo, costo e qualità. Si sottolinea poi che si tratta di parametri tra loro interdipendenti. È evidente infatti che una riduzione di du-

rata del progetto si ripercuote in generale sulla qualità dei risultati o sui costi di

realizzazione. Mentre tempi e costi di realizzazione sono parametri immediata-

mente comprensibili, il concetto di qualità del risultato di progetto richiede qualche commento. Esso include infatti, si pensi per esempio al settore dell’engineering & contracting, sia il rispetto dello «scope of work» — cioè i limiti di

fornitura — che la conformità ai requisiti tecnici contrattuali.

In ogni caso occorre sottolineare che i tre parametri citati — tempo, costo e qualità — sono l’oggetto della azione di pianificazione e controllo propria del Project Management. Ogni processo operativo del progetto — per esempio la . posa di una pipeline — deve essere completato soddisfacendo i requisiti contrattuali e rispettando prefissati vincoli di tempo e di costo.

PROGETTO

E PROJECT MANAGEMENT

9

Se si considera il processo di controllo del progetto, una diversa triade, che meglio mette a fuoco gli aspetti dinamici del progetto, è basata per esempio sui

seguenti parametri: avanzamento, modifiche, rischio (cfr. Fig.1.2). Vengono messe a fuoco le variazioni dello «scope of work» e/o delle specifiche di prodotto (change), dell’avanzamento del progetto (progress) e dei rischi realizzati-

vi (risk).

Il paradigma cui ci si riferirà nello sviluppo successivo del testo (cfr. Fig. 1.2) introduce un’evoluzione ulteriore, considerando una triade basata su: va-

lore, baseline di progetto, rischio. È possibile così estendere l'ampiezza del ciclo di vita del progetto considerando oltre alla fase realizzativa vera e propria anche la fase preliminare di impostazione, corrispondente nel caso dell’engineering & contracting alla fase di competitive bidding, cioè di partecipazione alla gara per l’assegnazione del contratto. Il concetto di valore percepito dal

cliente («project value») descrive la corrispondenza del progetto ai requisiti espliciti e impliciti del committente, il piano di realizzazione («project baseline») sintetizza i vincoli posti alla realizzazione del progetto in termini di tempo, costo e specifiche tecniche mentre il rischio («project risk») descrive gli eventi incerti che possono influenzare il progetto determinando uno scostamento sia dalle aspettative del committente («efficacia») che dal piano di realizzazione («efficienza»). Nella fase preliminare del progetto esiste ovviamen-

te un «trade off» tra «project value» e «project baseline»: ogni incremento di valore del progetto si traduce inevitabilmente in un incremento dei vincoli realizzativi. Il fenomeno rischio può intervenire poi a influenzare entrambi i ver-

santi considerati (cfr. Cap. 15).

RISK

VALUE TIME

/\

COST Fig. 1.2

.

QUALITY

| parametri gestionali del progetto

BASELINE PROGRESS

CHANGE

RISK

10

GESTIONE DEI GRANDI PROGETTI

1.5

Criteri di successo

DI INGEGNERIA

Se ampliamo la visione del progetto considerandone non solo l’intero ciclo di vi-

ta ma anche gli effetti strategici e soprattutto l'insieme degli stakeholder coinvol-

ti, anche la definizione di successo del progetto subisce un ampliamento, al di là della triade valore, baseline e rischio che abbiamo precedentemente introdotto.

Possiamo ritenere cioè che il successo del progetto implichi la soddisfazione dei diversi stakeholder coinvolti e riguardi quindi una molteplicità di aspetti: ° redditività; ° funzionalità tecnica; e accettabilità sociale; * sostenibilità ambientale;

° legittimità politica;

¢ sviluppo economico locale; ° ecc.

Possiamo cioè distinguere diverse dimensioni del successo di un progetto: » »

successo della gestione del progetto; successo del risultato del progetto;

*

successo dell’impatto sul contesto più ampio e di lungo periodo.

* successo del contributo al business da parte del progetto;

Il primo aspetto del successo riguarda i processi operativi, gestionali e organizzativi tipici del progetto. Viene messa a fuoco prevalentemente l'efficienza

del progetto, soprattutto in termini di tempi e costi richiesti per il suo comple-

tamento. Il secondo aspetto riguarda i deliverable del progetto in particolare in

termini di prestazioni funzionali. Il terzo aspetto riguarda il contributo del progetto al business del committente in termini di benefici attesi e posizionamento

strategico. Il quarto aspetto riguarda gli effetti indotti dal progetto su scala più

ampia, per esempio in termini di sviluppo economico a livello locale. 1.6

Organizzazione del progetto

Il progetto può anche essere definito come un’organizzazione temporanea, che delimita i confini del progetto stesso nell’ambito della società di appartenenza

o del contesto più ampio. Facendo riferimento al caso delle società di engineering & contracting, alla

macro-rete esterna — costituita dagli stakeholder del progetto — corrisponde una micro-rete interna, costituita dai diversi ruoli aziendali che, a vario titolo, sono

PROGETTO

E PROJECT MANAGEMENT

11

Strutture permanenti SPI

SP2

SP3

=

a

(CY)

CY

ci

a

C)

Cc 5)

O

C)

m O

(CY) VY

> I

(CY) O,

O

Éo

A

Fig. 1.3

o,

O

nw,

V4

O

Strutture permanenti e strutture temporanee (progetti)

coinvolti nella realizzazione del progetto. Tale micro-rete, costituita innanzitutto

dal Project Manager e dal Project Team, corrisponde di fatto a una struttura organizzativa temporanea, finalizzata al conseguimento degli obiettivi di progetto. Come è noto, le società di engineering & contracting, in quanto società operanti per progetti, sono caratterizzate da una matricialità intrinseca, che preve-

de la compresenza di strutture permanenti differenziate per funzioni — che fungono da «serbatoi» delle risorse specialistiche necessarie alla realizzazione dei

progetti — e di strutture temporanee interfunzionali — che coordinano l’impiego

delle risorse temporaneamente assegnate ai singoli progetti (cfr. Fig. 1.3).

La qualità dei processi organizzativi, in una società operante per progetti, di-

pende, in primo luogo, dalle modalità di interazione tra strutture permanenti e strutture temporanee.

Da questo punto di vista, l’approccio interfunzionale, tipico della gestione di

progetto, richiede uno spostamento dell’attenzione dalla struttura organizzativa permanente, fonte di differenziazione specialistica, ai processi operativi e ge-

stionali, che richiedono invece un elevato grado di integrazione dei diversi ap-

porti di tipo specialistico.

1.7

Il ciclo di vita del progetto

Il progetto è caratterizzato in generale da un ciclo di vita che si articola in una

sequenza standard di fasi:

12.

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA * * * e

fase fase fase fase

concettuale; di definizione; di realizzazione; di rilascio.

La fase concettuale riguarda l’impostazione del progetto. In questa fase emerge la strategia di progetto, per esempio in termini di scelte make or buy. Si tratta pertanto di definire la configurazione del prodotto/servizio da fornire, sulla base delle esigenze espresse dal cliente e di impostarne le relative moda-

lità realizzative. La seconda fase prevede la definizione dettagliata dei risultati attesi dal progetto (e quindi la progettazione esecutiva dell’impianto nel caso delle società di engineering & contracting) e dei relativi piani operativi di realizzazione.

Nel settore impiantistico un output tipico della prima fase riguarda per

esempio la definizione del macro-layout, in termini di allocazione delle unità d’impianto nell’area disponibile mentre la stesura dei micro-layout relativi alle

singole aree dell’impianto — per esempio i tracciati delle tubazioni — riguarda

la successiva fase di progettazione di dettaglio. La fase di realizzazione preve-

de la mobilitazione delle risorse necessarie per il completamento dell’iniziativa. Si arriva infine alla fase di rilascio, al trasferimento cioè, nel caso di forni-

tura a terzi, del risultato del progetto (per esempio l’impianto) all’utilizzatore

finale. Il ciclo di vita del progetto coincide con la durata della struttura temporanea (Project Team) adibita al coordinamento delle attività previste. La Tab. 1.2 riassume le caratteristiche principali delle singole fasi.

La Fig. 1.4 confronta per ciascuna fase del progetto l’influenza sui risultati di progetto con il costo richiesto per apportare azioni correttive.

Come si vede, la fase concettuale, che coinvolge una quantità limitata di risorse estremamente qualificate, pur presentando una esigua incidenza sui costi di progetto, condiziona in modo decisivo le prestazioni ottenibili in termini di

tempo, costo e qualità.

La fase realizzativa, cui corrisponde un’ingente mobilitazione di risorse, è in-

vece caratterizzata da una limitata possibilità di modificare «in corso d’opera»

Tab. 1.2

Le fasi del ciclo di vita del progetto

CONCETTUALE

determinante

REALIZZAZIONE RILASCIO

decrescente quasi nulla

DEFINIZIONE

elevata

impostata

dettagliata

congelata mantenuta

creativa

analitica

gestionale formativa

PROGETTO

E PROJECT MANAGEMENT

13

Influenza sui risultati

Y

Costo azione correttiva

Concettuale

Fig. 1.4

cia Definizione

Realizzazione

i . Rilascio

Andamento temporale dell'influenza sui risultati e del costo dell’azione correttiva

l’evoluzione del progetto, se non sostenendo costi rilevanti per il rifacimento di quanto è già stato fatto. Queste considerazioni stanno alla base di quello che può essere considerato

un assioma fondamentale del Project Management, vale a dire la criticità della fase di impostazione iniziale al fine di garantire il successo del progetto. La fretta di arrivare rapidamente alla mobilitazione delle risorse senza considerare le possibili alternative di impostazione del progetto può rivelarsi cattiva consigliera. Col progredire del ciclo di vita del progetto, cresce da una parte la definizio-

ne del prodotto/processo e dall’altra si riducono i gradi di libertà disponibili

per modificarne le caratteristiche. Di conseguenza il costo di eventuali azioni

correttive presenta un andamento rapidamente crescente. Gli andamenti riportati in Fig. 1.4 spiegano l’esistenza, nel ciclo di vita caratteristico del progetto, di un intervallo temporale in cui risultano più facilmente prevedibili e «governabili» gli esiti finali del progetto. Tale intervallo si trova attorno all’interfaccia tra definizione e realizzazione del progetto. Nel caso dell’engineering & contracting, esso corrisponde alla fase temporale in cui

l’ingegneria ha raggiunto un consistente grado di avanzamento mentre l’atti-

Vità di cantiere si trova nella fase iniziale ed è caratterizzato infatti sia da un

elevato grado di definizione tecnica dell'impianto da realizzare che da un elevato «potenziale» correttivo (in quanto le modalità di mobilitazione delle risorse sono ancora in parte modificabili senza variazioni di costo rilevanti).

14

GESTIONE

DEI

GRANDI

PROGETTI

DI INGEGNERIA

Ciclo di vita dell’investimento iniziale Pianificazione

strategica

Fattibilità

Contratto

|Realizzazione|

Esercizio

Dismissione

Ciclo di vita dell’impianto ee Progetto

2

Esercizio

|Smantellamento

Ciclo di vita del progetto

Fase concettuale

Fig. 1.5

Definizione

|Realizzazione

Rilascio

Il ciclo di vita dell’investimento, del progetto e dell'impianto

del progetto.

Il ciclo di vita dell’investimento, in quanto espressione del punto di vista del

committente, prevede l’identificazione di una opportunità strategica, una valu-

tazione di fattibilità, la decisione di procedere con una gara tra più offerenti, l’assegnazione del contratto, la realizzazione dell’impianto da parte del contrac-

tor prescelto, l'esercizio dell’impianto in modo da ottenerne i benefici attesi e infine la dismissione. Nel ciclo di vita dell’impianto distinguiamo un transitorio iniziale — la realizzazione — un stato stazionario centrale — la fase di esercizio — e un transitorio finale — lo smantellamento. Sono possibili anche altri progetti

lungo il ciclo di vita dell’impianto, per esempio progetti di manutenzione o am-

modernamento. Nel settore engineering & contracting il ciclo di vita del progetto di realizzazione si articola in una sequenza tipica di fasi: ingegneria di base,

ingegneria di dettaglio, approvvigionamento, mento e collaudo.

costruzione/montaggio,

avvia-

Capitolo 2

li ciclo di vita del progetto nel settore engineering

& contracting

2.1

introduzione

Il progetto costituisce dunque il problema da affrontare. Il Project Management rappresenta la risposta al problema. Facendo riferimento al settore dell’enginee-

ring & contracting, è opportuno pertanto mettere a fuoco innanzitutto la natura del problema e solo successivamente introdurre le tecniche di Project Management, in modo da verificare nel paragone col problema se tali tecniche rappresentano una soluzione adeguata e dove eventualmente emergano delle criticità. Dovendo cogliere le caratteristiche intrinseche del progetto un buon punto di partenza è rappresentato sicuramente dal suo ciclo di vita, considerato ovviamente nella sua interezza. Innanzitutto possiamo dividere il ciclo di vita del progetto in due fasi fondamentali: la fase che precede il contratto e la fase che

segue il contratto. Potremmo dire che nella fase precedente il contratto il progetto si trova in una fase «fluida», la sua configurazione è cioè in fase di definizione, mentre nella fase post-contrattuale il progetto si trova in una fase «so-

lida», la configurazione è stata definita e la baseline di progetto deve essere rispettata. Il contratto rappresenta dunque l’evento centrale del ciclo di vita del progetto, esso «congela» le proposte presentate dal potenziale contractor e le

trasforma nei vincoli che guideranno la realizzazione del progetto. Scendendo a un maggior grado di dettaglio possiamo identificare nel ciclo di vita del progetto la seguente sequenza di fasi: ° fase di marketing;

* studio di fattibilità; * fase di competitive bidding;

* fase di realizzazione del progetto; ° fase di esercizio; ° fase di dismissione.

Queste fasi sono separate da eventi che rappresentano dei milestone facil-

mente identificabili lungo il ciclo di vita del progetto:

16

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

» Fase di Marketing =» decisione a procedere con lo studio di fattibilità; * Studio di fattibilità =» decisione a procedere con la gara per l’assegnazione del contratto; * Competitive bidding =» assegnazione del contratto; * Realizzazione del progetto = accettazione provvisoria da parte del cliente;

* Fase di esercizio (in garanzia) = accettazione definitiva; ° Fase di esercizio = decisione a procedere con la dismissione; e Fase di dismissione. Possiamo ora passare in rassegna con maggiore dettaglio la sequenza di fasi ed eventi che caratterizza il ciclo di vita del progetto. Dobbiamo tenere presente che una generica società di engineering & contracting può intervenire in fasi diverse e con compiti diversi lungo il ciclo di vita del progetto. Si tratta infatti di società specializzate nella fornitura di un’ampia gamma di servizi riguardanti la realizzazione di opere complesse:

* studi preliminari e di fattibilità;

*

ingegneria di base;

*

sione della fase realizzativa; approvvigionamento ed expediting delle forniture;

*

construction management;

* ingegneria di dettaglio; * assistenza al committente nell’assegnazione del contratto e nella supervi-

e avviamento e collaudo;

* formazione e addestramento del personale; * assistenza tecnica in fase di esercizio; * assistenza commerciale.

2.2

L'acquisizione del contratto

In termini commerciali il progetto rappresenta una transazione complessa ri-

guardante la fornitura di prodotti e servizi, specificamente progettati per creare

un bene, per esempio un impianto industriale, che produca benefici per il committente durante un esteso periodo temporale. Ogni progetto può essere visto in

realtà come due progetti che si sviluppano in parallelo: dal punto di vista del committente si tratta di un progetto di approvvigionamento e investimento men-

tre dal punto di vista del fornitore come un progetto di vendita e realizzazione. Dal punto di vista del committente, il processo decisionale che porta all’asse-

gnazione a una società di engineering & contracting del contratto per la realizzazione di un progetto è caratterizzato da una sequenza di fasi ed eventi caratte-

IL CICLO DI VITA DEL PROGETTO

NEL SETTORE ENGINEERING & CONTRACTING

17

ristici: l’identificazione e la selezione delle opportunità di investimento, lo studio di fattibilità tecnico-economica, la gestione della gara per l’assegnazione

del contratto, la negoziazione conclusiva con l’assegnatario del contratto e la

supervisione all’esecuzione del progetto. Come si vede, lo studio di fattibilità sancisce la validità dell’investimento, conclude la fase di pianificazione strategica e dà il «semaforo verde» alla gara di assegnazione del contratto. Dal punto di vista della società di engineering & contracting, lungo il ciclo

di vita del progetto, intervengono tre figure principali:

e Marketing Manager, orientato alla identificazione e sviluppo delle opportunità di vendita; » Proposal Manager, orientato alla preparazione, presentazione e negozia-

zione dell’offerta fino all’acquisizione del contratto; * Project Manager, orientato alla gestione del progetto.

Il passaggio di consegna tra una figura e l’altra assume ovviamente una rilevanza critica. Nel caso del passaggio di consegne al Proposal Manager l’atti-

vità di business intelligence svolta dal Marketing Manager risulta fondamentale per l’impostazione della strategia di gara; nel passaggio di consegne al Project Manager le promesse fatte al cliente dal Proposal Manager — una volta formalizzate nel contratto — diventano vincolanti per l’impostazione e la con-

duzione del progetto.

A) Fase di Marketing All’origine del progetto si collocano innanzitutto le esigenze del committente,

che devono trasformarsi progressivamente in requisiti formali di tipo funzionale, prestazionale e strutturale. Se si tratta per esempio di realizzare un impianto

di stoccaggio occorre definire le funzioni dell’impianto (per esempio ricevimento merci, stoccaggio intensivo, picking e spedizione merci), le prestazioni richieste (per esempio potenzialità ricettiva e di movimentazione), i compo-

nenti d’impianto utilizzati per lo stoccaggio e la movimentazione dei materiali nonché le relative modalità di integrazione mediante il layout generale dell’impianto. Obiettivo del Marketing Manager è quello di influenzare, per quanto possi-

bile fin dall’inizio, il processo decisionale del potenziale committente in particolare nella risoluzione degli aspetti di incertezza presenti:

* incertezza di necessità (definizione dei requisiti tecnici dell’impianto da realizzare); * incertezza di mercato (individuazione dei potenziali fornitori);

18

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

e

incertezza di operazioni (gestione della gara di assegnazione del contratto, supervisione del progetto e successivo esercizio dell’impianto).

Il committente tende a una definizione preliminare delle proprie esigenze, acquisendo informazioni da parte di potenziali fornitori. Il processo decisionale da parte del committente può essere notevolmente complesso, coinvolgendo diversi attori che a vario titolo vi partecipano (promotori, compratori, influen-

zatori, controllori, decisori ecc.) e sfocia, qualora l’iniziativa sia valutata pro-

mettente, nella decisione di sviluppare uno studio per verificare la fattibilità tecnico-economica dell’iniziativa stessa.

B) Studio di fattibilità

Lo studio di fattibilità prevede in generale l’analisi dei seguenti aspetti dell’iniziativa considerata: ¢ domanda commerciale;

e

caratteristiche funzionali e prestazionali;

* e * ° ° ° e * * *

impatto ambientale; processo produttivo e layout; fonti di approvvigionamento; organizzazione del personale; progetto di realizzazione; fonti di finanziamento; costi di esercizio; redditività dell’investimento; analisi di sensitività e di rischio; raccomandazioni conclusive.

—

~

* ubicazione dell’impianto;

Sulla base dell’esito dello studio di fattibilità viene presa la decisione da

parte del committente se procedere o meno con la gara di assegnazione del contratto per la realizzazione dell’impianto.

C) Competitive bidding Dal punto di vista del committente, le fasi in cui si articola la gara per l’aggiudicazione del contratto possono essere così schematizzate: ° preparazione dei documenti di gara;

e qualifica dei potenziali offerenti;

IL CICLO DI VITA DEL PROGETTO NEL SETTORE

ENGINEERING & CONTRACTING

19

* richiesta e ricevimento delle offerte;

* comparazione delle offerte sul piano tecnico e commerciale; * eventuale richiesta di integrazione delle offerte; * selezione del miglior offerente; e negoziazioni;

* adempimenti preliminari; *

assegnazione del contratto.

Dal punto di vista dell’offerente la fase di preparazione dell’offerta si artico-

la in una serie di passi:

e analisi preliminare dei documenti di gara; * decisione se partecipare o meno (in caso affermativo definizione della strategia di gara); * pianificazione del processo di preparazione dell’offerta;

° sviluppo della soluzione tecnica da proporre; * stima dei relativi costi; * sviluppo del profilo d’offerta;

* valutazione del valore competitivo dell’ offerta;

* analisi dei rischi; * eventuale revisione dell’ offerta;

* presentazione dell’offerta.

Una volta ricevuti i documenti di gara, sulla base delle informazioni rilevate nella fase di marketing (committente, oggetto del contratto, area geografica, possibili concorrenti ecc.) e sulla base del carico di lavoro esistente e della

strategia aziendale (sviluppo di nuove tecnologie, di nuove aree geografiche, di

nuove partnership ecc.) si decide se partecipare o meno alla gara e, in caso affermativo, la strategia di gara (fattori competitivi su cui far leva, eventuali partnership, fornitori ecc.). Sempre in caso affermativo occorre pianificare il processo di elaborazione dell’offerta: risorse, organizzazione, procedure, strumenti ecc., considerando che tale processo corrisponde a tutti gli effetti a un progetto. Con il contributo dei diversi specialisti occorre poi procedere allo svi-

luppo della soluzione tecnica da proporre al cliente e alla stima dei relativi costi. Sul versante commerciale occorre definire l’offerta tenendo conto di tutti i fattori competitivi rilevanti per la gara considerata. La valutazione conclusiva che porta alla definizione dell’offerta deve tener conto quindi, oltre che del valore competitivo dell’offerta e dei vincoli realizzativi per il progetto, anche dei

‘rischi/opportunita che possono interessare il progetto nella fase di gara, nella fase realizzativa e nella fase di esercizio dell’ opera realizzata.

In questa sequenza di passi un momento critico ¢ rappresentato sicuramente dalla decisione se partecipare o meno alla gara (bid/no bid decision). Tale deci-

20

GESTIONE DEI GRANDI

PROGETTI

DI INGEGNERIA

sione non può limitarsi a considerare le caratteristiche del potenziale progetto

ma deve più in generale considerare la situazione della società offerente, in

particolare per quanto riguarda:

* impatto sulla redditività prevista del portafoglio progetti;

* impatto sul livello di rischio previsto del portafoglio progetti; * impatto sul carico di lavoro previsto del portafoglio progetti; * coerenza con la strategia aziendale.

Alcuni dei fattori che possono influenzare la decisione bid/no bid sono per esempio:

* condizioni e procedura di gara; e dimensione e complessità del progetto;

ZI

e livello di concorrenza; ° affidabilità e reputazione del cliente; * esperienza in progetti similari;

* impegno finanziario richiesto; * ecc.

Un secondo passaggio estremamente critico è rappresentato dalla definizio-

ne del contenuto dell’offerta. L'offerta contiene innanzitutto una soluzione tecnica proposta per risolvere le esigenze implicite e i requisiti espliciti formulati dal committente. Tali requisiti possono limitarsi agli aspetti funzionali oppure intervenire anche sugli aspetti strutturali dell'impianto e/o dell’apparecchiatu-

ra. Facendo riferimento per esempio al caso di acquisto di vetture tranviarie da parte di una società di esercizio del trasporto pubblico locale, i requisiti tecnici comunicati al potenziale fornitore possono per esempio essere cosi sintetizzati: * vetture monodirezionali;

e pianale ultra-ribassato; * lunghezza di circa 35 metri; * capacità di trasporto di circa 280 posti; * e * * *

numero dei posti a sedere maggiore del 20% dei posti totali; struttura modulare; equipaggiamento di trazione e frenatura a inverter; climatizzazione del comparto passeggeri e della cabina di guida; impianto frenante conforme a norme UNIFER;

* ecc.

Occorre tuttavia sottolineare come il valore competitivo dell’offerta non sia

semplicemente riconducibile alle caratteristiche della soluzione tecnica propo-

IL CICLO DI VITA DEL PROGETTO NEL SETTORE

ENGINEERING & CONTRACTING

21

sta, ma dipenda anche da tutta una serie di «fattori competitivi» associati alla

soluzione tecnica proposta. I principali fattori di competitività di un’offerta nel

settore dell’engineering & contracting possono essere così riassunti:

* prezzie condizioni di pagamento;

° * ° ° * * °

tecnologia di processo; trasferimento di tecnologia; pacchetto finanziario; grado di nazionalizzazione delle forniture; tempi di consegna; esperienze recenti in settori impiantistici simili; caratteristiche dell’offerente o offerenti;

* deviazioni dalle clausole contrattuali proposte.

È possibile definire a questo punto il «profilo d’offerta» come l’insieme dei contenuti dell’offerta proposti per ciascuno dei fattori competitivi considerati:

tecnologia di processo, partner, fornitori ecc. La valutazione del valore compe-

titivo globale dell’offerta deve pertanto tener conto:

* dei fattori competitivi rilevanti per il potenziale committente;

* dell’importanza relativa che il potenziale committente assegna a ciascuno di essi; ° del valore comparativo dell’offerta considerata, per ciascuno dei fattori competitivi, in rapporto a quanto offerto dai concorrenti.

Solo nel caso di appalti pubblici i primi due elementi — parametri di valuta-

zione delle offerte e relativi punteggi — devono essere esplicitati formalmente nei documenti di gara. Nel caso più generale, tutte le conoscenze relative ai tre punti citati derivano sia dai documenti di gara che dalle informazioni via via disponibili nel corso della gara stessa. In ogni caso la stima dei profili d’offerta che verranno presentati dai potenziali concorrenti non può che basarsi su informazioni di business intelligence. È evidente per esempio che un concorrente momentaneamente caratterizzato da un basso carico di lavoro tenderà a un comportamento commerciale più aggressivo.

I passi da seguire ai fini della valutazione del valore competitivo dell’offerta

possono essere pertanto cosi descritti:

* identificare i fattori competitivi rilevanti;

* stimare l’importanza relativa di ciascuno di essi per il committente; ° definire il profilo d’offerta; * stimare il profilo d’offerta dei principali concorrenti;

22

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

* valutare comparativamente per ciascun parametro i profili d’offerta; * valutare il valore competitivo di ciascuna offerta;

* stabilire una graduatoria delle offerte e identificare quella vincente. Un approccio sistematico al problema può basarsi su un semplice modello a

punteggio. In Fig. 2.1 è riportato un esempio di applicazione di tale modello. Sono stati individuati quattro fattori competitivi e per ciascuno di essi il peso

corrispondente. Tale peso è in genere determinato dalle esigenze del committente o dal potere discriminante del parametro stesso. È evidente infatti che se

per esempio tutte e tre le offerte propongono contenuti analoghi per i fattori A

e B il fattore C viene ad assumere di fatto un elevato potere discriminante tra le

scuna di esse viene espresso un punteggio per ciascun fattore competitivo in termini di valutazione comparativa delle offerte. Pesando i punteggi e sommando per ciascuna offerta i valori ottenuti ne deriva una valutazione sintetica del valore competitivo dell’offerta, che consente di ordinare le offerte nell’or-

dine di preferenza A C B. Pur essendo i punteggi sufficientemente distribuiti in

modo uniforme tra le offerte, l’offerta A viene favorita dal fatto di avere un ottimo punteggio per quanto riguarda il tempo di consegna, fattore questo che riveste un elevato grado di importanza per il committente.

Come si vede una semplice metodologia a punteggio risulta estremamente

efficace in quanto consente di integrare informazioni non omogenee, di tipo

qualitativo e quantitativo, oggettivo e soggettivo consentendo di sfruttare tutte le informazioni provenienti sia dall'esperienza passata che dall’attività di busi-

ness intelligence. Tra le tecniche decisionali Multi-Attributo un altro approccio estremamente interessante è quello basato su AHP (Analytic Hierarchy Process) dove la graduatoria finale viene ottenuta attraverso un sistematico confronto a coppie, per ciascun fattore competitivo, delle alternative considerate,

in questo caso delle offerte pervenute. Il metodo, grazie alla ridondanza delle informazioni utilizzate, risulta, laddove intervengano valutazioni soggettive, da

una parte estremamente efficace nella elicitazione del parere degli esperti e dall’altra estremamente «robusto» nella definizione della graduatoria finale.

Fattori competitivi Prezzo Tecnologia Tempo consegna Referenze

Valore competitivo Fig. 2.1

Pesi

Offerta A

Offerta B

Offerta C

0.2 0.3 0.4 0.1

7 8 9 8

8 7 8 9

9 9 7 7

1

8.2

7.8

8

Valutazione comparativa di offerte mediante metodo a punteggio

IL CICLO DI VITA DEL PROGETTO

NEL SETTORE

ENGINEERING & CONTRACTING

23

Si osservi che il modello descritto viene di fatto utilizzato in termini deterministici dal committente, in quanto gli sono noti sia i fattori competitivi che il

loro peso che le offerte presentate dai concorrenti. Ben diverso è il problema per il concorrente per cui tutti gli elementi del modello sono di fatto soggetti a

incertezza. In termini quantitativi, volendo salvaguardare il grado di incertezza

che caratterizza il problema, si può ricorrere a un approccio probabilistico as-

sociando un range di valori (oppure una distribuzione probabilistica) ai diversi

elementi del modello e ricavare mediante simulazione la probabilità che l’offerta presentata risulti vincente sul piano competitivo.

La fase di definizione del profilo d’offerta rappresenta una fase estremamente critica nell’arco del ciclo di vita del progetto, in quanto se da una parte le infor-

mazioni disponibili sono estremamente scarse, dall’altra occorre prefigurare mediante l’offerta gli impegni contrattuali che poi dovranno essere rispettati in

fase di realizzazione del progetto. Durante la preparazione dell’offerta la società

di engineering & contracting — attraverso il Proposal Manager — sta di fatto promettendo qualcosa al potenziale cliente in termini di tecnologia, prezzo, tempo di consegna, assistenza tecnica post vendita ecc. e nello stesso tempo accettando i vincoli che ne deriveranno per il progetto — e quindi per il project manager — intermini di costo, tempo e prestazioni tecniche dell’impianto, vincoli che, in caso di successo dell’offerta, saranno sanciti a livello contrattuale. Si viene di fatto a creare un «trade-off» tra il «valore competitivo» dell’offerta — proporzionale alle promesse in essa contenute — e i vincoli contrattuali cui sarà soggetta l’esecuzio-

ne del progetto. Quanto più è elevato il valore competitivo dell’offerta tanto più aumenterà la probabilità di aggiudicarsi il contratto ma, d’altra parte, tanto più

vincolata sarà la fase realizzativa e quindi il rischio di costi addizionali.

D'altra parte le informazioni risultano scarse sia sul versante del «valore competitivo» del progetto (sono state comprese correttamente le esigenze del cliente? Chi saranno e come si comporteranno i concorrenti?) sia su quello del-

la «baseline» di progetto, cioè della preventivazione dei tempi e dei costi di

realizzazione.

2.3

li contratto

La firma del contratto sancisce il passaggio dalla fase di acquisizione del contratto a quella di realizzazione del progetto. Con il contratto le proposte contenute nell’offerta, e successivamente negoziate con il cliente, diventano vincoli

per la realizzazione del progetto. Indipendentemente dalla complessità del documento (può trattarsi di un insieme di volumi oppure di un semplice ordine d’acquisto) il contratto rappresenta un accordo legale mutuamente vincolante

che obbliga il fornitore a fornire prodotti o servizi all’acquirente a fronte di un corrispettivo definito anch'esso contrattualmente.

24

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

Tipici contenuti del contratto sono: *

«scopo» del lavoro;

° specifiche tecniche;

* scadenze di consegna; * prezzo e modalità di pagamento;

* e * *

clausola di revisione prezzi; ruoli e responsabilità delle parti; criteri di collaudo e accettazione del prodotto; garanzie sul prodotto;

°

penalie

¢ limitazioni di responsabilità del fornitore; * assicurazioni obbligatorie;

e * * *

incentivi;

|

garanzie fideiussorie da parte del fornitore; approvazioni del cliente; gestione delle richieste di modifica; meccanismi di gestione dei contenziosi. —

|

TTT

~

Gli stakeholder che partecipano alla realizzazione di un progetto nel settore dell’engineering & contracting si trovano di fatto a operare in un «ambiente

contrattuale». Sono infatti dei contratti a regolare il rapporto tra cliente e main contractor e tra quest’ultimo e i diversi fornitori. In Fig. 2.2 sono riassunti i principali tipi di contratto utilizzati nel settore dell’engineering & contracting.

Forfait.

=

Lump Sum Fisso

Compenso stabilito Prezzi unitari

\

Contratto

Rimborsabile

Fig. 2.2

Costanti

—

L

>>

Decrescenti

Cost Plus Fee

Classificazione dei diversi tipi di contratto

7

Indicizzato

IL CICLO Di VITA DEL PROGETTO NEL SETTORE

Il contratto «Lump

ENGINEERING & CONTRACTING

25

Sum» (prezzo prefissato onnicomprensivo) è analogo al

contratto «a corpo» (a forfait) previsto dal Codice Civile italiano. Qualora il contratto Lump Sum riguardi la realizzazione di un impianto «chiavi in mano» si ha il contratto Lump Sum Turn Key. A sua volta il contratto «Unit Price» è analogo al contratto «a misura» (a prezzi unitari); esso prevede che siano concordati pre-

ventivamente i prezzi unitari delle risorse impiegate nel progetto ma non il prezzo totale che verrà definito a consuntivo sulla base del volume complessivo di risorse utilizzate. Il contratto «Reimbursable» prevede la copertura a consuntivo

da parte del committente delle spese sostenute dall’esecutore del progetto. I diversi tipi di contratto possono prevedere l’applicazione di incentivi e di indici di «escalation» (cfr. Fig. 2.2). Per esempio il contratto «Cost Plus Fee»

prevede che oltre alla copertura dei costi sostenuti l’esecutore ottenga un margine prefissato. Un eventuale incentivo può essere legato al raggiungimento di prefissati obiettivi per esempio di tempo e/o costo «Cost Plus Incentive». In Fig. 2.3 è riportato un diverso tipo di classificazione dei contratti utilizza-

ti nel settore dell’engineering & contracting sulla base della loro estensione lungo il ciclo di vita del progetto. Per quanto riguarda «l’ampiezza» del contratto, i servizi offerti possono andare oltre la fornitura dell’impianto «chiavi in mano» (Turn-Key contract) (cfr.

Fig. 2.3) fino ad arrivare ai contratti di tipo Build-Operate-Transfer, che preve-

dono l’intervento del contractor anche nella fase di esercizio dell’impianto. Per

esempio, il contratto «Lump Sum Turn Key», uno dei più diffusi in ambito en-

gineering & contracting, coinvolge entrambe le classificazioni in quanto si tratta di un contratto a prezzo prefissato onnicomprensivo (Lump Sum) che ri-

Project Cash Flow Design

=

©

IL

«

Commissioning

Na

&_—

5

(© oO

.

2

Time

is)

i.

Decommissioning

Y

3

&

3

©

de

Traditional Construction

ie

ig,

3

[C2

>.

2 3

Diverse modalità di rappresentazione di uno stesso reticolo

1

150

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

basata sul diagramma di precedenza. Nella terza rappresentazione la suddivisio-

ne (splitting) delle attività — indispensabile nei primi due casi per descrivere la

parziale sovrapposizione temporale fra di esse — non è più necessaria, ottenendo una radicale semplificazione della rappresentazione grafica.

Il diagramma di precedenza estende la tipologia dei legami possibili tra le

attività, utilizzando anche i seguenti (cfr. Fig. 11.11):

SSij legame «start to start», indica il numero minimo di unità di tempo che de-

vono essere trascorse dall’inizio dell’attività precedente, affinché quella

successiva possa iniziare; FFij legame «finish to finish», indica il numero minimo di unità di tempo che

occorrono per completare l’attività successiva dopo il completamento dell’attività precedente;

FSij legame «finish to start», indica il numero minimo di unità di tempo che

devono trascorrere dal completamento dell’attività precedente affinché

SFy

l’attività successiva possa avere inizio (si noti che la tecnica CPM prevede unicamente il legame FSij = 0); legame «start to finish», indica il numero minimo di unità di tempo che devono trascorrere dall’inizio dell’attività precedente fino al completa-

mento dell’attività successiva.

Il lag nella relazione SS rappresenta quindi la porzione del predecessore che

deve essere completata prima che il successore possa iniziare, mentre il lag

(i)

d)

Fig. 11.11

(i)

|

Tipi di legame tra le attività nei diagrammi di precedenza

LA PROGRAMMAZIONE TEMPORALE

1517

nella relazione FF rappresenta la porzione del successore che rimane da com-

pletare una volta che il predecessore sia finito. Emerge come l’impiego di questi tipi di legame renda più agevole la rappresentazione di eventuali sovrappo-

sizioni temporali («overlapping») tra le attività. In Fig. 11.12 è rappresentata la sovrapposizione temporale tra due attività A e B sia in forma compatta utiliz-

zando il diagramma di precedenza che secondo lo schema tradizionale AOA tipico del CPM, che impone sia la suddivisione delle attività che l’impiego di attività fittizie. Nel caso dei diagrammi di precedenza il calcolo delle date «al più presto» e «al più tardi» (e di conseguenza l’individuazione del cammino critico) risulta notevolmente più complesso rispetto all’approccio CPM tradizionale. Nello sviluppo dei calcoli tipici del «forward scheduling» si devono considerare tutti i vincoli relativi ai predecessori della generica attività considerata (j), sia quelli riguardanti la data di inizio (legami SS e FS) che quelli riguardan-

ti la data di fine (legami SF e FF). Per determinare le date «al più presto» ESj ed EFj dell’attività in esame occorre calcolare la data risultante per ciascun

singolo predecessore (1) e scegliere poi quella massima, utilizzando le seguenti relazioni: FS: SS: FF: SF:

ESj ESj EFj EFj

= = = =

EFi ESi EFi ESi

+ + + +

lag + 1 lag lag lag — 1

In Fig. 11.13 é riportato un esempio relativo alla determinazione delle date ES ed EF per l’attività I che ammette predecessori multipli. Dapprima si proce-

de al calcolo della data di inizio attività (ES) per ciascun predecessore con le-

DBO

|

,

BO

|

I

y FFA Ssi Fig. 11.12

A

Overlapping di attività nello schema AoN e AoA

152

GESTIONE DEI GRANDI PROGETTI

A | 20

DI INGEGNERIA

|FS=0

171 | 190

B | 30 | FS=0 158 | 187 Cc

20

180 | 199

SS == 10

Attività

i

dD | 10 | sges

Durata

30

192 | 226 ES «EF

187 | 196

E | 40 | FF =10 177 | 216 F

25

| FF =18

182 | 206

Fig. 11.13

Esempio di applicazione del «forward pass» nei diagrammi di precedenza con predecessori multipli

gami del tipo SS e FS; la data di inizio «al più presto» dell’attività I è 192, ovvero la massima tra quelle trovate, infatti: i |

ES ES ES ES

(VA) (/B) (I/C) (I/D)

=190+0+1= 191 = 187+0+1= 188 = 180 + 10 = 190 = 187+ 5 = 192

|

| :

Si calcola quindi la data di EF con riferimento-ai predecessori con legami

del tipo FF e si sceglie quella massima, cioè 226, come data di fine «al più presto»:

EF (J) = 192 + 30-1 =221 EF (I/E) = 216 + 10 = 226 EF (I/F) = 206 + 18 = 224 In generale nell’approccio tradizionale CPM la data di inizio «al più presto»

ES più la durata DU determina la data di fine «al più presto» EF: EF = ES +

DU

— 1. Nei diagrammi di precedenza, tuttavia, ogni volta che un’attività ha

LA PROGRAMMAZIONE TEMPORALE

153

dei predecessori esterni per la sua fine (legami FF e SF), uno di tali vincoli puo

determinare la data di fine «al più presto», come nell’esempio riportato e si ottiene quindi EF — ES + 1> DU. In questo caso l’attività non può essere sviluppata con continuità, deve subire cioè un'interruzione intermedia, a meno

che non se ne posticipi l’inizio o si anticipi il vincolo esterno.

Per lo sviluppo dei calcoli relativi al «backward scheduling» si devono considerare tutti i vincoli relativi ai successori della generica attività considerata (1),

sia quelli riguardanti la data di inizio (legami SS e SF) che quelli riguardanti la

data di fine (legami FS e FF). Per determinare le date «al più tardi» LSi e LFi dell’attività in esame occorre calcolare la data risultante per ciascun singolo successore (j) e scegliere poi quella minima utilizzando le seguenti relazioni: FS: SS:

LFi = LS; — lag-1 LSi = LSj — lag

SF:

LSi-= LFj — lag + 1

FF:

LF = LF) — lag

In Fig. 11.14 è riportato un esempio relativo alla determinazione delle date LS e LF per l’attività I che ammette successori multipli. Dapprima si procede al calcolo della data di fine attività (LF) per ciascun successore con legami del tipo FS e FF; la data di fine «al più tardi» dell’attività I è 129, ovvero la minima tra quelle trovate, infatti:

FS=0 | A | 20 133 | 152 FS=5

B

30

143 | 172 Attività

Durata

|

30

95

129

LS

LF

FF=10|

©

| 40

100 | 139

ss=10|

È | 20 105 | 124

ss=15|]

Fig. 11.14

F | 30 118 | 147

Esempio di applicazione del «backward pass» nei diagrammi di precedenza con successori multipli

154

GESTIONE DEI GRANDI

PROGETTI

DI INGEGNERIA

LF (VA) = 133 -0—1 = 132 LF (I/B) = 143 —-5— 1 = 137 LF (I/C) = 139 — 10 = 129 Si calcola quindi la data di LS con riferimento ai successori con legami del tipo SS e si sceglie quella minima, cioè 95, come data di inizio «al più tardi»:

LS () = 129 — 30 + 1 = 100 LS (W/E) = 105 — 10 = 95 LS (I/F) = 118 — 15 = 103 In generale nell’approccio CPM la data di fine «al più tardi» LF meno la durata DU determina la data di inizio «al più tardi» LS: LS = LF — DU + 1.

Nei diagrammi di precedenza, tuttavia, ogni volta che un’attività ha dei successori esterni per il suo inizio (legami SS e SF), uno di tali vincoli può determinare la data di inizio «al più tardi», come nell’esempio riportato, e si ottiene quindi LF — LS + 1> DU. In questo caso l’attività non può essere sviluppata con continuità, deve subire cioè un’interruzione intermedia. Di conseguenza

l'introduzione dei legami FF e SS nei diagrammi di precedenza può influenza-

re in modo determinante il cammino critico del progetto.

11.6

CPM-Costi

Il problema del trade-off tempi/costi è implicito nell’applicazione delle tecniche reticolari, dal momento che ogni stima di durata delle attività presuppone

un’ipotesi sulla quantità di risorse che verranno allocate a ciascuna di esse. È

evidente infatti che un maggiore tasso di impiego di risorse dovrebbe compor-

tare una minore durata della generica attività e la riduzione di durata di una 0

più attività collocate sul cammino critico dovrebbe consentire la riduzione del-

la durata dell’intero progetto. Dato che, come si è visto, ogni riduzione di durata delle attività di progetto comporta costi addizionali, la tecnica CPM-Costi si

pone come obiettivo quello di individuare la durata ottimale del progetto, defi-

nita come la durata che minimizza i costi totali di progetto. Tali costi totali so-

no dati dalla somma di due tipologie di costo:

* costi indiretti di progetto, che includono, oltre ai costi generali e di supervisione, gli oneri finanziari o altri costi quali per esempio eventuali pena-

lità previste per il completamento in ritardo. Si tratta di costi il cui valore

è funzione della durata del progetto;

* costi diretti di progetto, che includono i costi dei materiali, dei mezzi opera-

tivi e del lavoro necessari per il completamento delle singole attività previste. Si tratta di costi il cui valore è funzione della durata delle singole attività.

LA PROGRAMMAZIONE TEMPORALE

155

Si ipotizza che la durata delle singole attivita possa essere ridotta allocando a esse una maggior quantita di risorse e quindi di costi diretti. Si assume inoltre che l’entità di tali risorse possa essere stimata, tradotta in valori monetari ed espressa come costo diretto per unità di tempo risparmiata. È possibile definire per ogni attività: e valori normali di tempo/costo associati all’attività. Il costo normale di un’attività è uguale al minimo dei costi diretti richiesti per completare l’attiVità stessa e il corrispondente valore di durata equivale alla durata normale; e valori «accelerati» di tempo/costo associati all’attività. La durata «accele-

rata» («crash») è la durata minima tecnicamente possibile e i costi «crash» sono i costi diretti minimi coi quali è possibile conseguire tale durata.

Nell’ambito del CPM-Costi, individuando in un piano cartesiano nelle due

coordinate «costo/durata» i punti corrispondenti al caso «normale» (DN, CN) e al caso accelerato (DA, CA), è possibile descrivere graficamente per ogni singola attività l'andamento, assunto lineare, del costo in funzione della durata (cfr. Fig. 11.15). L'andamento dei costi totali, diretti e indiretti in funzione della durata del

progetto è invece descritto nella Fig. 11.16. Come si può vedere si assume per i costi indiretti un andamento lineare: il prolungamento della durata del progetto di una unità di tempo comporta un costo marginale costante. I costi diretti presentano invece un andamento non lineare, crescente con la compressione tem-

Costi diretti

porale della durata del progetto; ciò è spiegato dal fatto che procedendo alla ri-

(Da, Ca)

(Dy, Ch)

uu

Durata di Fig. 11.15

Andamento del costo associato a un'attività in funzione della durata della stessa

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

aa Oe

Costi del progetto

156

Costi totali

Costi indiretti

Costi diretti

Durata ottimale Fig. 11.16

So

Durata del progetto di

CPM-costi e durata ottimale del progetto

duzione progressiva della durata del progetto si rende necessario intervenire su un numero crescente di cammini critici e quindi il costo marginale risulta rapi-

damente crescente. La durata ottimale del progetto è pertanto quella che bilancia esattamente il risparmio marginale (indiretto) del tempo risparmiato completando il progetto con una unità di tempo di anticipo, col costo marginale (di-

retto) necessario per ottenere tale risparmio. Dovendo procedere alla riduzione della durata di un progetto occorre quindi intervenire sul cammino (o sui cam-

mini) critici, dando priorità all’attività (o alle attività nel caso di più cammini

critici) per le quali la compressione temporale risulta meno costosa. A ogni ite-

razione si riduce di una unita temporale la durata del progetto fino a quando il costo marginale di riduzione della durata supera il risparmio di costi indiretti.

Assumendo

opportune ipotesi semplificative (la relazione costo/durata è de-

scritta da una funzione lineare continua, le attività sono fra loro indipendenti, la disponibilità di risorse è illimitata) il problema detealcolo della durata ottimale del progetto così come viene impostato nel CPM-Costi può essere risolto come problema di programmazione lineare.

11.7

Le tecniche reticolari come strumento di controllo

Il reticolo di progetto oltre che come strumento di programmazione iniziale può essere utilizzato come strumento di controllo durante lo sviluppo del pro-

getto. Esso consente sia di valutare eventuali ritardi maturati al time now che di

stimare il tempo necessario al completamento del progetto.

LA PROGRAMMAZIONE TEMPORALE

157

Una volta che il progetto è stato avviato, il reticolo impostato in fase di pianificazione iniziale può essere progressivamente aggiornato tenendo conto delle date effettive di inizio e fine delle attività già completate. In realtà, le attività

previste dal progetto possono essere al time now suddivise in tre gruppi:

* attività completate;

* attività iniziate ma non completate; *. attività programmate ma non iniziate.

Per le attività completate sono note le date effettive di inizio e fine. La percentuale di completamento è il 100% e la durata corrisponde alla durata effetti-

va rilevata. Per le attività avviate ma non completate sono note solo le date effettive di inizio. Può essere inoltre stimata la percentuale di avanzamento e il tempo ancora mancante per il completamento. La durata stimata dell’attività — e quindi la data di completamento prevista — dipenderà dalla somma tra il tempo tra-

scorso dall’inizio dell’attività più la stima a finire.

Per le attività programmate ma non avviate la percentuale di completamento è ovviamente nulla mentre per la durata vengono mantenuti 1 valori inizialmente stimati. Aggiornando in questo modo i dati del reticolo è evidente che le date di ini-

zio e fine delle attività non ancora avviate subiranno delle modifiche in rela-

zione all’andamento del progetto per la parte già completata. Anche il cammi-

no critico potrà cambiare. In particolare la data di completamento del progetto

subirà un aggiornamento. Emerge pertanto come le tecniche reticolari costituiscano uno strumento utilizzabile per stimare in itinere la data di completamento del progetto. Da que-

sto punto di vista emerge anche un limite: la durata delle attività incluse nella

quota di lavoro ancora mancante non subiscono adattamenti in relazione all'andamento del progetto — per esempio tendenze riguardanti la produttività delle risorse — nella parte già completata. Sotto questo aspetto le tecniche reticolari possono essere pertanto integrate con l’impiego di altri strumenti — basati sulla estrapolazione dell’andamento degli indici di performance rilevati nella parte di lavoro completata (cfr. Cap. 14) — caratterizzati da un maggior grado di sintesi e da una maggiore capacità di proiettare sulla quota di lavoro mancante i trend verificatisi nella quota di lavoro già realizzata.

L'aggiornamento dei dati del reticolo di progetto risulta comunque in gene-

rale complesso sia per quanto riguarda la parte di lavoro già svolta che, a maggior ragione, quella ancora da completare, per una serie di motivi: e

l’analiticità del metodo rende necessario trattare un numero molto elevato

di attività e di legami logici spesso sofisticati;

158

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

* occorre elaborare un notevole volume di dati, sia riguardanti gli attributi delle attività (durata, risorse, costi), sia eventualmente le leggi di variazio-

ne degli attributi al variare della durata; * la frequenza di aggiornamento dei dati col progredire del progetto costituisce un aspetto critico fondamentale per l’efficace utilizzo delle tecniche reticolari;

e irisultati elaborati a seguito di ogni aggiornamento devono essere verificati criticamente, analizzando l’evoluzione dei legami logici tra le attività del progetto. 11.8

Critical Chain

La rassegna delle tecniche reticolari non sarebbe completa senza alcuni cenni all’approccio basato sul concetto di «Critical Chain» sviluppato da E.M. Goldratt. Si tratta di un approccio fortemente innovativo sia nell’analisi delle criticità che

minano l’efficacia delle tecniche reticolari come strumenti della programmazione di progetto sia per le soluzioni proposte. I problemi che E.M. Goldratt identifica come caratteristici delle tecniche re-

ticolari possono essere suddivisi in due gruppi: strutturali Per quanto riguarda gli aspetti strutturali abbiamo:

e comportamentali.

* ivincoli riguardanti le risorse;

* ipunti di confluenza di più cammini in uno stesso nodo.

Per quanto riguarda i vincoli riguardanti le risorse è evidente come il classico cammino critico, definito in assenza di vincoli sulle risorse, sia scarsamente

attendibile come stima di durata del progetto. Si consideri per esempio la Fig. 11.17, in cui il cammino critico è descritto dalla sequenza di attività 1,2,6 cui

corrisponde una durata complessiva di 30 unità di tempo. Si osserva tuttavia

che le tre attività 3,4,5 che potrebbero essere svolte in parallelo in realtà utiliz-

zano la stessa risorsa X e quindi devono essere svolte in serie. La sequenza

3,4,5,6 rappresenta la vera durata complessiva del progetto di 40 unità di tem-

po e viene definita «critical chain». Il tema dei vincoli posti dalla disponibilità di risorse sulla durata del progetto verrà approfondito nel Cap. 12.

Anche 1 nodi del reticolo in cui si verifica la confluenza di più cammini rap-

presentano un fattore critico per la durata del progetto. Come evidenzia la Fig.

11.18 è il cammino più in ritardo — in figura quello con un ritardo di 5 unità di tempo — che condiziona la durata complessiva. Le due criticità strutturali evidenziate da E.M. Goldratt sottolineano proble-

mi in qualche misura già noti. Più originale l’evidenziazione delle criticità di

natura «comportamentale»:

LA PROGRAMMAZIONE TEMPORALE

S

i [

Y

10

xX,

Xx.

Fig. 11.17

159

Y 10

Y 10

Critical Path = 30 Critical Chain = 40

4/

5

Cammino critico e «critical chain»

—5 MERGING EVENT

-10

0

+5

—15

+5

Fig. 11.18

Confluenza di più cammini in un nodo

* stime previsionali distorte; * legge di Parkinson; * sindrome dello studente; * mancato completamento anticipato; » multitasking.

La distorsione della stima di durata delle attività (soprattutto se tale stima

viene effettuata da chi poi sarà incaricato della loro esecuzione) consiste nel-

l’introduzione sistematica in fase di programmazione di riserve temporali per ogni attività in modo da avere la garanzia di rispettare le scadenze di completa-

160

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

mento fissate. L'insieme di tutte queste riserve temporali comporta un’indebita estensione della durata prevista per il progetto.

Tale estensione si accompagna con effetti perversi alla legge di Parkinson la

quale prevede che il lavoro per ogni attività si espanda fino a riempire tutto il

tempo disponibile. Questo fenomeno è rinforzato dalla «sindrome dello studente» cioè dalla posticipazione del lavoro al periodo immediatamente prece-

dente la data pianificata di completamento. Il risultato è che pur ammettendo che la durata dell’attività sia descrivibile mediante una distribuzione probabilistica (ricavata dai dati storici per attività ripetitive oppure dalla valutazione di esperti per attività non ripetitive) e assumendo come scadenza pianificata il va-

lore atteso, in realtà non avviene mai una segnalazione di anticipo ma soltanto di ritardo; come se metà della distribuzione venisse di fatto annullata.

Infine il fenomeno del «multitasking» in forza del quale in un contesto multi

progetto gli incaricati della esecuzione delle attività si alternano tra un progetto e l’altro (cfr. Fig. 11.19) sulla base delle sollecitazioni di volta in volta prove-

nienti dai diversi progetti, ottenendo il risultato di posticipare oltre il dovuto tutte le attività in corso. A fronte delle criticità «strutturali» e «comportamentali» evidenziate, E.M.Goldratt propone una serie di rimedi: * stima «aggressiva» della durata delle attività; * riserve temporali centralizzate;

¢ abolizione di date pianificate di inizio/fine delle attività; °

introduzione di «resource buffer».

/ /

i

Ipotizzando che la durata della singola attivita sia descritta da una distribuzione probabilistica, la stima di durata utilizzata in fase di programmazione do-

MULTITASKING

A

A completed

B completed

A

B

B

Cc

A

B

i

Cc

C completed

=

C

A

B

Cc

A completed B completed C completed Fig.

11.19

Multitasking

LA PROGRAMMAZIONE TEMPORALE

161

vrebbe approssimare la mediana, in modo da avere la stessa probabilità di anti-

cipo e ritardo, il che corrisponde alla radicale eliminazione di qualsiasi riserva temporale distribuita alle singole attività. A copertura dei possibili imprevisti, le riserve temporali devono essere centralizzate sui diversi cammini: innanzi-

tutto ovviamente occorre prevedere una riserva («project buffer») per la «critical chain». Siccome la «critical chain» rappresenta il «collo di bottiglia» per la durata dell’intero progetto, va opportunamente protetta dai possibili effetti di

ritardo indotti dai cammini non critici in essa confluenti mediante dei «feed

buffer» assegnati ai singoli cammini. L'innovazione più radicale proposta da E.M. Goldratt riguarda tuttavia l’a-

bolizione delle date pianificate di inizio/fine delle attività in modo da elimina-

re tutti i fenomeni comportamentali che determinano l’estensione del lavoro fino alla data di completamento pianificata. I milestone di progetto vengono so-

stituiti da resource buffer cioè da segnalazioni anticipate con cui l’incaricato dell’attività in via di completamento segnala all’incaricato dell’attività successiva l'imminente passaggio di consegne.

Capitolo 12

La gestione delle risorse

12.1

Introduzione

L'esecuzione di una generica attività di progetto richiede l’impiego di risorse,

tra queste in particolare il lavoro che in generale rappresenta la risorsa più

strettamente correlata con l’avanzamento del progetto. Abbiamo visto come

l’allocazione biamo anche costringere a terminologia

di risorse alla generica attività possa influenzarne la durata. Abvisto come vincoli sulla disponibilità di risorse nel tempo possa rivedere la programmazione iniziale del progetto. Seguendo la introdotta da E.M. Goldratt il «collo di bottiglia» del progetto non

è tanto il cammino critico derivante dalla semplice considerazione delle relazioni di precedenza temporale quanto la «catena critica» che tiene conto anche dei vincoli derivanti dalla disponibilità di risorse. Tali vincoli possono addirittura compromettere la fattibilità e l’economicità del piano di progetto.

In fase di pianificazione preliminare è possibile tracciare un diagramma tempificato delle attività di cui il progetto si compone (per esempio un diagramma di Gantt); noto il fabbisogno di risorse di ciascuna attività è possibile poi delineare il profilo temporale del fabbisogno di risorse del progetto. Facendo riferimento a una specifica risorsa, per esempio le ore-uomo di montaggio,

si ottiene un profilo del tipo riportato in Fig. 12.1.-4m generale si tratterà tuttavia di un problema multi-risorsa che richiederà la stesura di una serie di diagrammi del tipo descritto. In alternativa è possibile limitarsi a considerare la ri-

sorsa o le risorse più critiche. Occorre inoltre fare un’ulteriore precisazione. Nel diagramma di Fig. 12.1 si è assunta l’ipotesi che il tasso di impiego della risorsa sia costante lungo l’intera durata dell’attività. Sono in realtà possibili

anche differenti modalità di impiego delle risorse lungo la durata dell’attività. Dato che in una società di engineering & contracting si verifica in generale

la contemporanea presenza di più progetti, in genere tra loro interagenti se non altro per l’utilizzo di risorse comuni, più che della gestione di un singolo pro-

getto è corretto parlare della gestione di un «portafoglio progetti». Data la

struttura «a matrice» delle società operanti per progetti esiste poi una stretta in-

LA GESTIONE DELLE RISORSE

Diagramma di Gantt

Attivita

A

163

GEN

FEB

MAR

APR

MAG

GIU

LUG

Tempo

LUG

Tempo

Profilo dell'impegno di risorse del progetto

GEN Fig. 12.1

FEB

MAR

APR

MAG

GIU

Lo programmazione del progetto.

terdipendenza tra la pianificazione dei progetti e quella delle strutture perma-

nenti. La struttura permanente fornisce infatti, nello stesso tempo, risorse a più progetti, ciascuno caratterizzato da una diversa estensione temporale e da un diverso profilo temporale di fabbisogno delle risorse, rendendo necessaria

quindi una verifica di compatibilità tra il fabbisogno di risorse complessivamente richiesto dai progetti periodo per periodo e la capacità resa disponibile

per ogni risorsa (cfr. Fig. 12.2). Per semplicità in Fig. 12.2 si ipotizza che ogni progetto abbia una sola attività che richiede l’impiego della risorsa considerata. La pianificazione del portafoglio progetti consente di ottenere un risultato

estremamente importante: la stima del fabbisogno di risorse che graveranno

sulle singole strutture permanenti e quindi, se la stima è sufficientemente anticipata, l’adozione di opportune azioni correttive tese ad aumentare la disponi-

bilità di risorse nei periodi in cui il fabbisogno eccede la disponibilità, per

esempio mediante ricorso a contratti di subfornitura. Occorre in ogni caso sot-

tolineare che sia il progetto che la struttura permanente dispongono di gradi di

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

ies)

Progetti

164

Profilo dell'impegno di risorse della struttura

Capacità

disponibile

GEN Fig. 12.2

FEB

MAR

APR

MAG

La programmazione della struttura permanente.

GIU,

LUG

Tempo

|

libertà utilizzabili al fine di evitare sovraccarichi localizzati di lavoro sulla sin-

gola struttura permanente; da una parte il progetto può rivedere la pianificazione iniziale collocando diversamente le attività non situate sul cammino critico e dall’altra la struttura permanente può modificare la programmazione di eventuali progetti interni, per esempio di formazione. In tutti i casi è evidente che quanto maggiore è l’anticipo con cui il sovraccarico viene individuato tanto

più è possibile intervenire. Soltanto in assenza di interventi volti ad ampliare la disponibilità di risorse nei periodi critici si verifica un superamento del fabbisogno sulla disponibilità di risorse e di conseguenza occorre definire delle regole di priorità con cui assegnare ai progetti le scarse risorse disponibili. Per i progetti a bassa priorità, per i quali non sono disponibili risorse sufficienti, si porrà pertanto il problema di programmazione «a capacità finita» che può comportare anche la posticipazione di attività collocate sul cammino critico e quindi ritardi di completamento.

LA GESTIONE DELLE RISORSE

12.2

165

La gestione delle risorse di progetto

Qualora i vincoli relativi alla disponibilità di risorse non siano stati preventiva-

mente rimossi a livello della pianificazione del portafoglio progetti, si rende necessario un approccio alla programmazione e controllo del singolo progetto,

che, come mostrato in Fig. 12.3, tenga conto in modo sistematico dei vincoli relativi alla scarsità di risorse disponibili. A livello della singola attività occorre innanzitutto risolvere il problema del

trade-off tra allocazione di risorse e durata dell’attività. A livello dell’intero progetto occorre per ogni tipologia di risorsa e per ogni periodo dell’intervallo di programmazione valutare il fabbisogno complessivo verificandone la compatibilità con la disponibilità prevista.

Disaggregazione del progetto in attività

À

Y

Vv Vincoli di

Stima della durata precedenza

delle attività

pre A

e del fabbisogno di risorse Fase di

Vv Revisione durata

a

e fabbisogno risorse

pianificazione

CPM

eg

br

A Pupranificazione

delle risorse

A

mm

NO

\—

Verifica dei vincoli

legati a tempi/risorse

SI

NO

Il progetto in avanzamento

soddisfa il piano?

SI |

rN

Report perdiodici:

Y

Implementazione del piano

di ase Il 1 controle

|

stato di avanzamento |g e risorse utilizzate

Fig. 12.3

v A

Procedura di pianificazione e controllo di un progetto

v

166

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

Ai fini della programmazione del progetto il metodo del Cammino Critico nella sua versione base presenta limiti rilevanti. Esso, infatti, si basa sull’ipotesi di capacità infinita, non tiene conto cioè dei vincoli derivanti dal profilo

temporale di disponibilità di risorse lungo il ciclo di vita del progetto. L'ipotesi di capacità infinita genera, nella gestione del progetto, numerosi inconvenienti che possono rendere infattibile il piano ottenuto: * reperire le risorse pianificate può essere o troppo costoso o addirittura impossibile; *

le risorse specialistiche non sono intercambiabili (per esempio gli specialisti «elettrici» non sono utilizzabili in attività di tipo «meccanico», avendo essi capacità, conoscenze, esperienze totalmente diverse);

* la non anticipazione dei vincoli relativi alle risorse porta in generale a un aumento dei costi, in quanto queste devono spesso essere recuperate in condizioni di urgenza. Occorre quindi adottare una metodologia che incorpori sistematicamente ed

esplicitamente i vincoli legati alle risorse all’interno del processo di program-

mazione e controllo del progetto. L'obiettivo della gestione delle risorse quindi è quello di tenere conto, nel programmare le date di inizio e fine di ogni attività, della variabile «capacità», bilanciando 1 costi derivanti dall’utilizzo di maggiori risorse (per esempio manodopera straordinaria) con i costi causati dallo spostamento della data di completamento del progetto (per esempio penali contrattuali).

Occorre considerare tutti i tipi di relazioni di precedenza che legano le attività di un progetto: | 1. Precedenze «naturali» 2. Precedenze «ambientali»

3. Precedenze «preferenziali».

1. Le relazioni di precedenza «naturali» rappresenitano i vincoli inalterabili di sequenza delle attivita (per esempio: prima di realizzare le strutture di un edificio occorre aver terminato le fondazioni...) e sono le sole relazioni considerate nel metodo del Cammino Critico nella sua versione base.

2. Le relazioni di precedenza «ambientali» sono invece legate al particolare contesto in cui il progetto viene realizzato, in particolare ai vincoli di dispo-

nibilità di risorse (per esempio: due attività, che non possiedono vincoli di

precedenza di tipo naturale, e che richiedono una speciale work station, pos-

sono essere svolte in parallelo solo qualora esistano due work station del ti-

po richiesto, altrimenti devono venir realizzatein serie). I vincoli derivanti

dalla disponibilità di risorse, possono pertanto essere classificati come «am-

LA GESTIONE

DELLE RISORSE

167

bientali». In particolare si parla di risorse rinnovabili quando il vincolo è posto sul tasso di impiego relativo alla risorsa (per esempio la forza lavoro disponibile nell’unità di tempo), e di risorse non rinnovabili quando il vincolo è sulla quantità totale disponibile (per esempio il budget di progetto); naturalmente vi possono essere anche risorse doppiamente vincolate, sia sul tas-

so di impiego che sulla quantità globale.

3. Le relazioni di precedenza «preferenziali» riflettono solamente le scelte di

chi pianifica. Esse influenzano il processo di pianificazione in modo analogo alle relazioni di tipo «ambientale».

Le relazioni di precedenza «naturali» rappresentano vincoli stabili in quanto sono indipendenti dal tempo e dal tipo di schedulazione che viene scelta per le attività, mentre i vincoli sulle risorse sono vincoli dinamici perché dipendono

dal tipo di schedulazione che viene realizzata. Il formarsi di un «collo di botti-

glia» localizzato e temporaneo a causa dell’insufficienza di risorse disponibili può dipendere da scelte di programmazione effettuate a monte, costringendo alla posticipazione di una o più attività collocate sul cammino critico e influenzando così tutto lo sviluppo successivo del progetto fino alla data di completamento.

Considerando tutti i legami di precedenza sopra descritti, e non solo quelli

«naturali», la programmazione del progetto — sequenza delle attività, date di

inizio e fine, margini di scorrimento, profilo di utilizzo delle risorse — risulta

radicalmente diversa da quella ottenuta con un approccio basato sui soli legami «naturali». I vincoli relativi alle risorse hanno infatti un effetto indipendente rispetto ai vincoli di precedenza. Una volta applicata la procedura di program-

mazione a capacità finita, il cammino critico può mutare radicalmente e i total float inizialmente calcolati a capacità infinita perdono di significato. In generale, una metodologia di programmazione del progetto può articolarsi nei seguenti passi: 1. Programmazione a capacità infinita: * definizione delle attività da eseguire; e stima della durata delle attività; * determinazione delle relazioni «naturali» di precedenza tra le attività;

» «calendarizzazione» delle attività.

2. Valutazione del fabbisogno aggregato di risorse: * stima del fabbisogno di risorse per ogni attività; * aggregazione per ogni periodo dell’intervallo di pianificazione e per ogni risorsa del fabbisogno derivante dalle diverse attività; * valutazione del profilo temporale di fabbisogno aggregato delle risorse;

* confronto col profilo di disponibilità delle risorse; * qualora il profilo di disponibilità delle risorse sia insufficiente si procede con una revisione della programmazione di progetto.

168

GESTIONE DEI GRANDI

PROGETTI DI INGEGNERIA

3. Livellamento delle risorse (Resource leveling): e processo di riduzione delle fluttuazioni del profilo temporale di fabbiso-

gno delle risorse (cfr. Fig. 12.4). Si possono in questo modo ridurre possi-

bili diseconomie nell’utilizzo delle risorse. 4. Programmazione a capacità finita (Resource Constrained Project Scheduling Problem): ° si tratta di programmare il progetto rispettando vincoli tassativi sulla disponibilità di risorse (cfr. Fig. 12.4).

Mentre la procedura di programmazione a capacità finita garantisce la fatti-

bilità del progetto, la procedura di livellamento del profilo di fabbisogno delle risorse consente soltanto di migliorare l’economicità di realizzazione in quanto tende a mantenere per ogni risorsa un tasso di impiego il più possibile costante.

La metodologia di gestione delle risorse che si sviluppa secondo 1 passi sopra elencati, è utile sia che si stia operando in un’ ottica di lungo periodo che in una di breve periodo. Nel primo caso si svolgono solo i primi due passi e si valuta il

profilo di impiego delle risorse per identificare i periodi di potenziale «overload»

in modo da impostare anticipatamente strategie di intervento alternative: fornitori esterni, nuove assunzioni, lavoro straordinario, subappalto, cambiamento degli obiettivi ecc. Quando invece l’ottica in cui si sta agendo è di breve periodo e i

o

À

9 Overload

oA

Vi

oc

|

_ | ia

Tempi fissi

2

©)

D a

Tempo [|

D a

>

Tempo

Fig. 12.4

À

ra)

Q

ir

Programmazione a tempi fissi e risorse fisse

Risorse fisse

LA GESTIONE DELLE RISORSE

169

vincoli non sono più modificabili non resta che procedere alla programmazione a capacità finita (Resource Constrained Project Scheduling Problem) assegnando sulla base di prefissati criteri di priorità le scarse risorse disponibili.

Come si è visto, sia che si programmi a capacità infinita o finita, l’obiettivo

che si persegue è in generale dato dalla minimizzazione della durata del progetto. In alternativa si può porre l’obiettivo di massimizzare il Net Present Value sempre rispettando i vincoli di disponibilità di risorse. Si osservi che la

massimizzazione del Net Present Value associato al progetto prevede una sche-

dulazione «al più tardi» delle attività a cui sono associati degli esborsi ed «al

più presto» di quelle legate agli incassi. In generale il completamento del progetto al più presto può non rappresentare la scelta ottimale qualora vengano

considerati anche gli aspetti finanziari.

12.3

Programmazione a capacità finita

Il problema

di programmazione

a capacità

finita (Resource

Constrained

Project Scheduling Problem) è un problema complesso di tipo combinatorio.

Le tecniche risolutive possono essere raggruppate in due grandi categorie: 1. Tecniche di ottimizzazione 2. Tecniche euristiche

Le prime — in genere del tipo branch and bound — puntano a produrre una schedulazione «ottima» di tipo globale, considerando cioè tutte le attività asso-

ciate al progetto nonché i relativi vincoli di tipo naturale e ambientale, ma presentano dei limiti che le rendono di fatto impraticabili: * eccessiva onerosita di calcolo; » definizione «statica» del problema; » difficoltà a determinare i criteri di «ottimalità», tenuto conto dei diversi possibili obiettivi in conflitto. Gli approcci di tipo euristico invece non possono garantire una soluzione «ottima» globalmente, essi tuttavia costituiscono un approccio razionale finalizzato all’ottenimento di un risultato quanto meno accettabile trasformando la

soluzione del problema globale nella soluzione di una sequenza di problemi di ottimizzazione locale. A ogni passo la soluzione parziale ottenuta per la parte di reticolo già elaborata viene estesa nel tempo fino ad arrivare progressivamente alla conclusione del progetto. Nel caso di problemi di dimensioni sufficientemente complesse, le tecniche euristiche costituiscono di fatto l’unico approccio possibile, essendo le tecni-

.

170

GESTIONE

DEI GRANDI PROGETTI

DI INGEGNERIA

che di ottimizzazione di fatto impraticabili. Anche le tecniche euristiche presentano ovviamente dei limiti: e possono perseguire, in ogni schedulazione, un solo obiettivo alla volta; * ottengono performance diverse a seconda delle caratteristiche del reticolo cui sono applicate; ° si basano su regole di priorità (per risolvere i conflitti tra le attività che ri-

chiedono risorse comuni) fissate a priori, senza quindi possibilità di adattamento alle caratteristiche del progetto.

Una metodologia euristica efficiente dovrebbe allocare le risorse in modo tale da perseguire contemporaneamente i seguenti obiettivi: * minimizzare il ritardo del progetto; ¢ minimizzare le interruzioni nell’impiego delle singole risorse; * massimizzare la saturazione delle risorse disponibili. Tali obiettivi possono essere perseguiti mediante un approccio euristico articolato nei seguenti passi:

1. Costituzione della lista delle attività programmabili, per le quali sono cioè

soddisfatti 1 vincoli di precedenza «naturali». 2. Individuazione, nell’ambito della lista precedentemente definita, di tutti i gruppi di attività «fattibili», il cui fabbisogno totale di risorse è cioè compatibile con

la disponibilità di risorse (le risorse in gioco possono essere infatti più d’una). 3. Calcolo, per ogni gruppo «fattibile» di attività, dell’impatto previsto sulla

data di completamento del progetto, qualora il gruppo stesso di attività venisse programmato alla data considerata. 4. Allocazione delle risorse al gruppo di attività che minimizza il ritardo del progetto.

5. Spostamento in avanti lungo l’orizzonte di programmazione fino alla prossima data in cui è possibile far iniziare una o più attività, essendo disponibili le risorse.

In Fig. 12.5 è schematizzata la procedura di programmazione a capacità finita precedentemente descritta.

12.4

Regole di priorità

Un approccio semplificativo rispetto a quello precedentemente descritto, che prevedeva come si è visto la valutazione, per ogni gruppo di attività «fattibile»

LA GESTIONE DELLE RISORSE

171

START

Y

Si sottrae dalla disponibilità di risorsa la frazione utilizzata dalle attività in progress

Vv

Si identificano le attività idonee (rispetto dei vincoli naturali)

Y

SI

Le risorse sono sufficienti per tutte le attività idonee?

Si identificano le risorse per cui vi è conflitto

Si schedulano le attività che non generano conflitti Si generano tutti i subset possibili delle attività rimanenti

Y

Si valuta ogni subset fattibile x» | _

3 -

Si allocano le risorse a tutte le attività del migliore subset

Si avanza all'istante temporale successivo in cui si libera la risorsa

.

y

A

Tutte le attivita sono state schedulate?

END

Fig. 12.5

Diagramma di Resource Scheduling

NO

172

GESTIONE DEI GRANDI

PROGETTI DI INGEGNERIA

alla data, dell’impatto sulla durata del progetto, si basa sull’impiego di regole

di priorità, del tutto analoghe alle regole di «dispatching» utilizzate nello scheduling operativo, per dirimere il conflitto tra attività diverse che competono per accedere a risorse comuni. Tali regole di priorità possono essere suddivise in due famiglie, la prima centrata su parametri di tipo temporale, la seconda su parametri attinenti la modalità di impiego delle risorse. Esempi di regole appartenenti alla prima famiglia:

1. MIN SLK («Minimum Job Slack»)

Il conflitto per l’accesso a risorse comuni da parte di differenti attività viene risolto dando priorità all’attività caratterizzata dal minor margine di slittamento (il quale, come visto precedentemente, è dato dalla differenza tra tempo di inizio al più tardi e tempo di inizio al più presto). . RSM («Resource Scheduling Method») Viene data precedenza all’attività i caratterizzata dal minimo valore del parametro dij, corrispondente all’incremento della durata del progetto che si verifica quando l’attività j segue l’attività i, con:

dij = max [0; (EFTi — LST})] dove:

EFTi = tempo di fine al più presto dell’attività i LSTj = tempo di inizio al più tardi dell’attività j

Il confronto viene effettuato fra tutte le coppie appartenenti all’insieme di

attività in conflitto per l’accesso a risorse comuni. Questa regola fornisce risultati analoghi a quelli prodotti dalla regola MIN LFT di seguito descritta.

. MIN LFT

(«Minimum Late Finish Time»)

Questa regola sequenzia le attività dando precedenza a quelle con valori minori della data di fine «al più tardi».

. MIN LST («Minimum Late Start Time»)

Si da precedenza alle attività con valori minori della data di inizio «al più tardi».

. SJF («Shortest Job First»)

Viene data priorità alle attività che presentano il minor valore di durata.

. LJF («Longest Job First»)

Viene data priorità alle attività che presentano il maggior valore di durata.

Questa regola tenta di prevenire conflitti per l’accesso alle risorse nelle fasi

terminali del progetto.

. L-PATH («Longest Path»)

Per ogni attività viene calcolata la durata del cammino fino al completamen-

to del progetto. Viene data priorità all’attività caratterizzata dal cammino più

lungo.

LA GESTIONE

DELLE RISORSE

173

Esempi di regole appartenenti alla seconda famiglia: 8. GRD («Greatest Resource Demand»)

Questa regola usa come criterio di priorita il fabbisogno di unita di risorsa

(tenendo conto di tutti i tipi di risorse richieste) associato a ogni attivita, dando precedenza a quelle caratterizzate da un fabbisogno maggiore.

Il grado di priorità associato a ogni attività viene così calcolato: e

i

N

Priorita = d;: dr, i= |

dove:

d, = durata dell’ attivita j 1; fabbisogno per unità di tempo della risorsa di tipo i da parte dell’attività j m = numero dei differenti tipi di risorse. La logica sottesa a questa regola è quella di dare priorità alle attività che possono creare dei potenziali colli di bottiglia. 9. GRU («Greatest Resource Utilization»)

Questa regola concede priorita, in ogni intervallo di programmazione, a quella combinazione di attivita che consente di ottenere la massima satura-

zione possibile delle risorse disponibili. 10. MJP («Most Jobs Possible») Questa regola da priorita a quella combinazione di attivita che consente di programmare il massimo numero possibile di attivita in ciascun intervallo

di programmazione. Differisce dalla regola GRU in quanto la determina-

zione del massimo numero possibile di attivita tiene conto unicamente del-

la fattibilità (cioè della disponibilità di risorse sufficienti) e non del grado di saturazione di queste ultime.

Altre regole (ACTIM, ACROS, ACTRES, ROT) considerano l’insieme dei cammini controllati dalla singola attività in competizione per l’accesso a risorse scarse e assegnano la priorità alle attività sulla base di parametri associati a tale insieme di cammini quali: durate, risorse, prodotto durate per risorse, risorse per unità di tempo. Per esempio viene scelta prioritariamente l’attività che controlla un insieme di cammini che coinvolge il maggior valore di durata

complessiva o di impiego delle risorse. Sulla base di una serie di esperimenti condotti, è possibile concludere che in generale le regole che forniscono i migliori risultati sono: MIN SLK, RSM, LFT, LST. Altre regole (per esempio GRU e SIO) hanno dimostrato tuttavia

una notevole efficacia nella soluzione di problemi multiprogetto. In generale non esiste una regola che fornisca sistematicamente risultati migliori delle altre, indipendentemente dalle caratteristiche del problema considerato. Nei casi

174

GESTIONE DEI GRANDI

PROGETTI DI INGEGNERIA

in cui la riduzione della durata del progetto rivesta particolare importanza (e

non siano praticabili tecniche di ottimizzazione) è pertanto opportuno applicare più di una regola. Le principali caratteristiche del reticolo che influenzano le prestazioni otte-

nibili mediante le regole considerate possono essere così riassunte:

* rapporto tra fabbisogno medio di risorse per singola attività e disponibi-

lità globale di risorse (la regola MIN SLK è particolarmente sensibile a

questo parametro); * rapporto tra numero

di attività e numero

(«complessità del reticolo»).

delle relazioni di precedenza

Le regole di priorità precedentemente definite possono essere applicate uti-

lizzando sia un APPROCCIO «IN SERIE» - il livello di priorità delle attività è predeterminato e rimane fisso lungo tutta la procedura di schedulazione — che un APPROCCIO «IN PARALLELO» - il livello di priorità delle attività viene aggiornato ogni volta che un’attività viene schedulata —. L'approccio «in parallelo» date le sue caratteristiche «dinamiche» produce nor-

malmente risultati migliori. Lo scheduling delle attività viene effettuato prenden-

do in considerazione un periodo di tempo alla volta, in ogni periodo le attività pronte per l’inizio (i cui predecessori sono stati cioè già programmati) vengono

ordinate sulla base di una regola di priorità (per esempio per valori crescenti dello

slittamento totale). Successivamente, sulla base della sequenza così stabilita, viene programmato il maggior numero possibile di attività, compatibilmente con la disponibilità di risorse; le attività che non possono essere schedulate per insufficienza di risorse vengono posticipate al periodo successivo. Alla fine di ogni pe-

riodo, prima di spostarsi al successivo, vengono aggiornate sia la disponibilità di

risorse sia le date «al più presto» e «al più tardi» delle attività posticipate. Questa procedura viene ripetuta fino alla completa programmazione del progetto. L'approccio «in serie» prevede invece che tutte leaîtività previste dal progetto vengano ordinate un’unica volta all’inizio dell’attività di programmazione,

utilizzando una prefissata regola di priorità (per esempio per valori crescenti dello slittamento totale). Le attività vengono programmate una alla volta non appena i loro predecessori sono stati programmati rispettando la sequenza precedentemente definita. | Mentre l’approccio «in serie» tende a programmare le attività seguendo uno

alla volta i cammini che caratterizzano il reticolo, per ordine di criticità decrescente e compatibilmente con vincoli di precedenza, l’approccio «in parallelo» interviene alternativamente sui diversi cammini e procede da un periodo al successivo. L'approccio seriale, dal momento che l’ordine di priorità delle atti-

vita è fissato a priori, è di tipo statico e quindi meno efficace rispetto all’ap-

proccio in parallelo.

Capitolo 13

La baseline dei costi

13.1

Introduzione

Il progetto riceve in input risorse di vario genere (lavoro, materiali, servizi, mezzi operativi) e genera come output l’avanzamento «fisico» del progetto stesso in termini di documenti tecnici elaborati, ordini emessi, materiali installati ecc. L'impiego di risorse si traduce in costi operativi mentre l’avanzamento si traduce in ricavi operativi. Sulla base dei termini di pagamento concordati a

livello contrattuale, costi e ricavi si traducono poi in esborsi e incassi andando a determinare il cash flow di progetto.

L'andamento cumulato nel tempo dei costi sostenuti per il progetto tende ad assumere la classica configurazione della curva ad S; in particolare l’andamen-

to cumulato dei costi «preventivati» costituisce un riferimento fondamentale («cost baseline») per il controllo economico-finanziario del progetto.

Iniziando ad affrontare il problema del controllo economico-finanziario dei

progetti è importante mettere in evidenza quali siano le caratteristiche proprie del progetto. Faremo questo ricorrendo a un esempio che, per semplicità, chia-

risce quale sia il problema chiave nel controllo dei progetti, e quali siano gli approcci gestionali più opportuni per realizzare un controllo efficace!.

I problemi che devono affrontare oggi molte società di engineering & contrac-

ting sono per certi versi analoghi a quelli che si presentavano ai diversi mercanti che nella Venezia di 500 anni fa erano dediti al commercio con l’Estremo Oriente. Consideriamo allora un gruppo di finanziatori che abbia acquistato delle mercanzie prodotte nell’Italia settentrionale e noleggiato una carovana per venderle in India. Con il ricavato della vendita i mercanti acquistavano tè, tornavano a Venezia e lo rivendevano. Il profitto dell’intero viaggio era alla fine facilmente determinabile dal contabile, il quale deduceva i costi della carovana e del carico

iniziale dai proventi della vendita del tè. È però evidente che non era possibile ai finanziatori richiedere allo stesso contabile di calcolare l’utile della spedizione ! H.T. Johnson, R. Kaplan, Ascesa e declino della contabilità direzionale, ISEDI, Torino 1989.

176

GESTIONE DEI GRANDI PROGETTI DI INGEGNERIA

nel terzo trimestre del 1495, quando la carovana stava attraversando il deserto persiano sulla strada per l’India. Anche allora probabilmente capivano che si sarebbe trattato di una esercitazione contabile senza senso. Tuttavia i finanziatori della spedizione sarebbero stati certamente interessati a conoscere indicatori di altro tipo, tipicamente «operativi», utili a valutare il probabile risultato della spe-

dizione stessa, come per esempio: quanta distanza aveva percorso la carovana e in quale direzione, quante provviste erano rimaste, quali erano le condizioni del-

le persone assoldate e delle merci. L'utile infatti si sarebbe consolidato solamen-

te al termine del viaggio, con la rivendita del tè; ciò nonostante, numerose e di diversa natura potevano essere le informazioni utili ai finanziatori per avere

«sotto controllo» l'andamento e il grado di successo della spedizione. I finanziatori, con ogni probabilità, conoscevano abbastanza precisamente quanto avrebbero potuto realizzare dalla rivendita del tè sul mercato interno,

mentre molto meno sapevano di quanto lo avrebbero pagato e se la qualità sa-

rebbe stata soddisfacente, così come abbastanza approssimativa era la conoscenza della strada che la carovana avrebbe dovuto percorrere e di cosa avrebbe

incontrato, tanto da rendere critica la possibilità di rispettare i tempi richiesti dal

mercato. Possiamo dunque concludere che il controllo economico finanziario del progetto risulta estremamente problematico e deve costantemente fare leva

su valutazioni di avanzamento fisico e su parametri di prestazione operativa. D'altra parte il progetto si sviluppa all’interno di un contesto aziendale. In una società operante per progetti possiamo infatti distinguere diversi livelli gestionali tra loro interagenti: ° gestione di progetto; * gestione del portafoglio progetti;

* gestione delle strutture permanenti; * gestione aziendale.

Tutti e quattro i livelli possono essere fonte di azioni correttive per il singolo pro-

getto. Nell’ambito della gestione di progetto, per esempio, una riallocazione di risorse può essere decisa al fine di rispettare un milestone di importanza rilevante dal punto di vista contrattuale. Nell’ambito della gestione del portafoglio maggiori in-

vestimenti o un maggior livello di priorità possono essere assegnati a progetti di rilevanza strategica. Nella gestione delle strutture permanenti alcune attività di progetto possono essere riprogrammate per livellare il carico di lavoro della struttura permanente. Nell’ambito della gestione aziendale una maggiore priorità può essere assegnata a progetti che offrono un contributo positivo ai risultati di esercizio.

La gestione di portafoglio è determinante nella definizione di politiche commerciali — per esempio scelte bid no bid — in quanto determina il carico di lavoro complessivo gravante sulle risorse interne aziendali sull’intero orizzonte di

pianificazione. In generale la gestione di portafoglio evidenzia le interdipen-

LA BASELINE DEI COSTI

177

denze tra i progetti in termini di tecnologia, mercato e risorse. Il dimensionamento delle strutture permanenti a sua volta rappresenta una scelta strategica in quanto se da una parte condiziona come si è visto il carico di lavoro ammissibile dall’altra determina il livello dei costi generali che devono essere poi ripartiti tra i diversi progetti attivi. Nell’ambito della gestione aziendale emergono poi i riflessi finanziari, civilistici e fiscali dei progetti.

Possiamo quindi distinguere:

* un processo di controllo economico-finanziario che accompagna il singo— lo progetto lungo tutto il suo ciclo di vita, in genere di durata pluriennale;

* un processo di valutazione dell’impatto economico-finanziario del progetto sui risultati aziendali di esercizio, su base tipicamente annuale.

La visione della gestione di esercizio corrisponde a una «finestra temporale»

all’interno dell’orizzonte di pianificazione definito dal portafoglio progetti nel suo complesso (cfr. Fig. 13.1). Se da una parte il risultato di esercizio deriva sostanzialmente, anno per anno, dalla sommatoria dei risultati ottenuti dai singoli progetti in corso, dall’altra si crea un’inevitabile conflitto tra l’orizzonte plurien-

nale tipico della gestione di progetto e la cadenza annuale di esercizio aziendale.

Il confronto sistematico dei dati di costo stimati a preventivo con quelli rilevati a consuntivo durante il ciclo di vita del progetto consente i/ controllo dei costi

di progetto, laddove l’attenzione sarà principalmente focalizzata sulle voci di costo effettivamente controllabili dal project manager; in parallelo occorrerà inol-

tre controllare l'impatto del progetto sul risultato d’esercizio aziendale estenden-

Costi

progetto A

progetto B

progettò C

Tempi

Fig. 13.1

Relazione tra gestione di esercizio e gestione del portafoglio progetti

178

GESTIONE DEI GRANDI PROGETTI

DI INGEGNERIA

do l’attenzione a tutti gli aspetti coinvolti (civilistici, fiscali, finanziari ecc.). Al

termine del progetto, quanto tutti i costi saranno noti in modo definitivo, sarà

possibile procedere a una valutazione conclusiva dei risultati economico-finan-

ziari del progetto e del loro contributo al risultato d’esercizio aziendale.

13.2

L'articolazione del progetto in voci di controllo

La Work Breakdown Structure costituisce la base per il processo di controllo dei costi di progetto.

Sulla base della disaggregazione del progetto in Work Package, possono essere definiti i «Control Account» (o Cost Account), corrispondenti in generale

a singoli WP o ad aggregati di WP omogenei. I Control Account possono esse-

re definiti come «voci di controllo» gestionale in cui vengono rilevati i costi effettivi e questi ultimi confrontati coi costi preventivati in fase di pianificazione del progetto. I CA, una volta definiti, rappresentano pertanto il massimo grado di dettaglio di controllo dei costi di progetto. Il passaggio dai WP ai Control Account non è automatico. In Fig. 13.2 sono

evidenziate diverse modalità di aggregazione dei Work Package in Control Account. In generale questo può essere fatto sia secondo gli elementi di WBS — aggregando cioè i costi per elementi di prodotto — sia secondo gli elementi di OBS — aggregando cioè i costi secondo le strutture permanenti che intervengo-

no nel progetto (cfr. Fig. 13.2). | Una volta definita l’articolazione del progetto in voci di controllo (Control Account), durante la realizzazione del progetto si verifica un duplice flusso: 1. un flusso di risorse finanziarie, che attraversa la WBS

dall’alto verso il bas-

so secondo un processo di crescente disaggregazione e che consente l’allo-

cazione delle risorse finanziarie ai singoli CA; n 2. dato che i WP, e quindi i CA, corrispondono agli elementi del progetto in cui si verifica l’impiego delle risorse (con i conseguenti costi operativi), esiste poi

un flusso informativo che risale la WBS dal basso verso l’alto secondo un processo di crescente aggregazione finalizzato al controllo dei costi di progetto.

L’ammontare delle risorse finanziarie distribuite ai CA, in una certa fase di avanzamento del progetto, risulta dalla seguente ripartizione: Ricavo contrattuale Profitto

~ —

Riserva (Contingency)

=

Budget Budget non distribuito

=

Budget distribuito ai CA

LA BASELINE DEI COSTI

ie)

3

s

wes

MOTORE

BS

85

QE E

(e)

a

[=

EÉ

$8

®

n ©

DD