Insegnamento di Gestione e Organizzazione dei Progetti Ciclo di

Insegnamento di
Gestione e Organizzazione
dei Progetti
A.A. 2008/9
Lezione 5:
ciclo di vita di un progetto
strutture organizzative
il Project Charter
Prof.ssa R. Folgieri
email: [email protected]
[email protected]
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
1
Ciclo di P.M. (Project Management)
• Nello schema sono rappresentate le varie fasi del ciclo di PM, precedute
dall’AVVIO DEL PROGETTO, che abbiamo identificato con la fase 0 (e il relativo
dicumento di valutazione) di studio di fattibilità.
• Vi sono, comunque, varie rappresentazioni del ciclo di vita di un progetto, utili a
seconda del tipo di progetto o aderenti allo standard del committente
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
2
1
Altre rappresentazioni del ciclo di vita: Difesa USA
- Il sistema di acquisizione del Ministero della Difesa Americana, prevede fasi e
deliverable di ciasuna milestone, secondo lo schema seguente:
Milestone 0
Faseability Study
approval
Milestone II
Technical Project
approval
Milestone I
Demonstration
approval
Milestone IV
Main Modification
approval
Milestone III
Production approval
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
3
Altre rappresentazioni del ciclo di vita: Morris
- La rappresentazione di morris (nello schema seguente) viene utilizzata per progetti
di costruzioni
Completamento (%)
Feasibility
Studio di fattibilità
Progetto strategico
Approvazione
Planning & Design
Progetto di base
Costi e tempi
Termini contrattuali
Condizioni
Planning dettagliato
Completamento
sostanziale,
realizzazione
Definizione
pricipali contratti
Production
Manufacturing
Consegne
Opere civili
Istallazioni
Test
decisione di
procedere
Stage 1
Stage 2
operatività
Turnover &
startup
Test finali
Manutenzione
Stage 3
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
Stage 4
4
2
Altre rappresentazioni del ciclo di vita: Murphy
- Utilizzata per i progetti di prodotti farmaceutici
test clinici
test stabilità
lavoro preclinico
origine
screening per richiesta
pratica
medicinale migliori
IND
IND
ph I
ph II
ph III
pratica
NDA
attività di
controllo
metabolismo
tossicologia
Processo di autorizzazione
scoperta
screening
sviluppo preclinico (oltre 10 anni)
registrazione lavoro
approvazione
IND Æ Investigation New Drug application
NDA Æ New Drug Application
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
5
Altre rappresentazioni del ciclo di vita: PLM
Product Lifecicle Management
• Obiettivo: ottimizzare (minor tempo, minori costi, maggiore qualità, minori rischi) lo
sviluppo, la modifica e il ritiro dei prodotti o servizi dal mercato.
• Strategia che permette all’impresa di innovare il prodotto durante tutto il cilco di vita
(fino all’obsolescenza), creando archivio di capitale intellettuale riutilizzabile (basato
su accesso condiviso a fonte comune da cui attingere informazioni e processi
relativi al prodotto). Molto utile in progetti di innovazione• Composto da vari moduli, organizzati nelle categorie:
•
Document Management: gestione della documentazione tecnica
(CAD/CAM/CAE) e di progetto.
•
Product Structure Management: gestione della configurazione di prodotto
(Struttura).
•
Configuration management: gestione di varianti e lotti di produzione.
•
Change management: gestione cambiamenti di entità che descrivono il prodotto.
•
Workflow management: gestione del flusso aziendale dei dati.
•
Catalog Library: gestioni dei componenti normalizzati e delle parti standard (viti
bulloni, resistenze .....).
•
Supply Chain Management: gestione scambio dati con i fornitori.
La scelta dei moduli da prevedere dipende dal grado di integrazione voluto per il
processo produttivo.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
6
3
Altre rappresentazioni del ciclo di vita: a spirale
- Utilizzata per i progetti di sviluppo software
Immagine tratta da wikipedia
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
7
Altre rappresentazioni del ciclo di vita: a cascata
Per lo sviluppo del software (c’è anche la metodologia waterfall) - il primo modello di ciclo di vita
del software.
•
il processo di sviluppo è diviso in fasi sequenziali
•
output di ogni fase usato come input dalla fase successiva
•
ogni fase del processo viene documentata.
Fasi del modello a cascata tradizionale:
•
studio di fattibilità. Scopo: determinare se avviare lo sviluppo del sistema
•
analisi dei requisiti. Scopo: determinare cosa farà il sistema
•
progetto. Scopo: determinare come il sistema farà quanto stabilito, la sua suddivisione in
moduli e le relazioni fra questi
•
codifica, o sviluppo. Scopo: creazione dei moduli con un linguaggio di programmazione
•
collaudo. Scopo: verificare la correttezza dell'implementazione dei singoli moduli
•
integrazione (o test di integrazione). Scopo: verificare la correttezza del funzionamento
complessivo del sistema
•
manutenzione. Scopo: dopo la consegna o delivery del prodotto, attività volte a migliorare,
estendere e correggere il sistema nel tempo.
Svantaggi:
•
difficile stimare le risorse e i costi in maniera accurata prima del completamento della prima
fase di analisi;
•
specifica dei requisiti: documento scritto che vincola il prodotto da sviluppare e non sempre
soddisfa le esigenze del cliente che spesso appaiono chiare dopo il primo rilascio del software
•
l’utente spesso non conosce tutti i requisiti dell’applicazione
•
il modello obbliga a usare standard di documentazione tali da rischiare la burocratizzazione
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
8
4
Altre rappresentazioni del ciclo di vita: a cascata
Fonte:http://www.csse.monash.edu.au/
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
9
Altre rappresentazioni del ciclo di vita: evolutivo
Sviluppo ICT. Supera il modello a cascata.
Si basa sulla prototipizzazione (realizzazione rapida di una versione semplificata del
sistema informativo), per la sperimentazione di funzionalità. La verifica del prototipo
può portare a una modifica dei requisiti e una eventuale revisione del progetto.
La prima versione va dunque considerata “throw-away” ("cestinabile") valida finché non
fornisce un feed-back sufficiente.
La seconda versione può essere sviluppata seguendo il modello cascata.
Poche fasi che si ripetono:
• Realizzazione di un prototipo
• Consegna del prototipo all’utente
• Raccolta delle valutazioni dell’utente
• Modifica del progetto in funzione delle valutazioni
Soluzione parziale ai problemi del modello a cascata (elimina gli errori nei requisiti ma
non riduce la distanza temporale per il completamento del ciclo di sviluppo).
Le fasi possono essere anche concorrenti (si riducono i tempi, ma aumentano i rischi)
Si è evoluto nel modello incrementale.
Svantaggio maggiore: rischio di indisciplina. Necessari standard di processo.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
10
5
Altre rappresentazioni del ciclo di vita: incrementale
Per sviluppo ICT. Prevede le fasi:
• analisi dei requisiti
• progetto
• codifica
• test (o collaudo)
Si ottiene la prima versione funzionante del prodotto software;
si procede poi con la seconda iterazione, che prevede le fasi:
• analisi dei requisiti
• progetto
• codifica
• test (o collaudo)
e si ottiene la seconda versione del prodotto, anch'essa funzionante.
Si procede allora fino all'ennesima iterazione, finchè non si arriva ad un
progetto solido.
Consigliabile quando si ha una visione sufficientemente chiara dell'intero progetto sin
dall’inizio, perché occorre fare in modo che la realizzazione della generica versione k
risulti utile per la realizzazione della versione k+1.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
11
Altre rappresentazioni del ciclo di vita: a fontana
Modello per ICT,
• altamente iterativo,
• particolarmente adatto per metodologie orientate agli oggetti e
• per grandi progetti cui partecipano molte persone,
• utile specialmente se il progetto riguarda prodotti “mission critical” che non possono
fallire
Si basa sul concetto che anche se alcune attività non possano iniziare prima di altre,
(es. codifica e progettazione) sussiste forte sovrapposizione tra le attività durante il
ciclo di sviluppo.
Si chiama modello a fontana perché nel disegno sono presenti degli zampilli, anche a
livelli inferiori, che indicano i casi in cui, per conoscenze sopraggiunte in corso di
progetto, occorre ripianificare e quindi risalire la fontana.
Permette lo sviluppo di componenti software maggiormente autonome, all’interno di
un’infrastruttura unificante (integrazione).
Si potrebbe dire che tende alla costruzione di un “ repository” in cui immagazzinare
componenti riutilizzabili (considerevole risparmio di tempo dovuto al parallelismo).
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
12
6
Altre rappresentazioni del ciclo di vita: a fontana
Fonte:http://www.csse.monash.edu.au/
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
13
Altre rappresentazioni del ciclo di vita: iterativo
- Un altro esempio di rappresentazione per ICT è il modello iterativo.
- Nella categoria dei modelli iterativi rientrano tutti i processi di sviluppo che permettono
di ritornare ad una fase del procedimento già affrontata in precedenza. In ogni fase si
tende a partire con una prima bozza della soluzione che seguirà successivamente
raffinata al prossimo passaggio.
- Vi sono tante altre rappresentazioni.
- Non le elencheremo tutte. Abbiamo visto le principali.
- Ciascuna dipende dalle caratteristiche del progetto
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
14
7
Ciclo di P.M. (Project Management)
• Se facciamo riferimento al modello generico che abbiamo utilizzato per
introdurre il ciclo di P.M.(o project life cycle), ci accorgiamo che:
• le fasi (cui attribuire i gruppi di processi PMI) generalizzano tutti i modelli
• le 4 fasi e i gruppi o i singoli processi, ricorrono, in modi diversi o in
diversa successione, in tutti i modelli.
4 fasi:
• stabilire obiettivi
qualitativi e quantitativi
• pianificare e programmare
costi e tempi
• mettere in atto
il piano di lavoro
• valutare i risultati
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
15
FASE 1: ANALISI E PORTATA DI UN PROGETTO
FASE 1
•
•
•
•
•
•
Il progetto è approvato. Occorre specificare in dettaglio.
A volte (è il caso dei progetti europei o dei progetti commissionati) si è
indotti a pensare che fase 0 e fase 1 siano unificate. In realtà c’è sempre
una fase di analisi e di produzionedi specifiche di dettaglio.
In questa fase tutti i capitoli della fase 0 vengono ripresi, dettagliati in
sottocapitoli, e dettagliati.
I documenti che vengono prodotti sono quelli che guideranno tutte le fasi
del progetto:
– Project Charter: riporta i termini dell’autorizzazione formale del
progetto
– Descrizione dell’ambito del progetto: collegato al precedente,
stabilisce quale lavoro occorre eseguire e quali deliverable produrre
– Piano di Project Management: tipico di questa fase, stabilisce come
deve essere eseguito il lavoro
Il progetto è corredato poi di molti documenti a corollario (qualità, rapporti di
stato d’avanzamento, specifiche tecniche, documenti di exploitation), tutti
conservati nel repository di progeto (es. wiki)
Il piano di progetto, in tutte le sue parti, vive ed è aggiornato per tutta la
durata del progetto.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
16
8
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Struttura organizzativa e progetto
• Un progetto è spesso parte di strutture organizztive pi ampie (il progetto è
circoscritto nel tempo, ricordate?
• A volte può rappresentare un’organizzazione (ad es. in caso di startup)
• In termini di prestazioni, un progetto dipende fortemente dalla sua struttura
organizzativa
• Possiamo distinguere (PMI):
• Organizzazioni orentate ai progetti: le operazioni sono costituite
principalmente da progetti, ovvero:
• il loro obiettivo è gestire/lavorare a progetti (es. società di
consulenza)
• hanno adottato un modus operandi che segue la gestione per progetti
• Le organizzazioni che non sono invece orientate a progetti (ad es.
molte aziende di produzione, manifatturiere, artigiane), sono solitamente
poco efficaci. In questo caso vengono create sotto-organizzazioni Projectoriented.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
17
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Strutture organizzative
• In alcuni casi nell’ambito di un progetto alcuni stakeholder (e spesso
proprio il Project Manager) operano come amministratori delegati e si
ha una struttura gerarchica che accentra poteri e responsabilità nella
figura del Project Manager. Dunque vi è necessità di:
–
dare ai Project Manager elevata libertà d’azione. Si
hanno quindi vincoli di strutture estremamente verticali, con
forte connotazione gerarchica
–
Seguire una politica di controllo e valutazione delle
prestazioni molto stringenge e dunque predisporre
procedure operative puntuali e strumenti efficaci
• Problema in questo caso: trovare un corretto bilanciamento tra
potere e responsabilità per garantire che non si traduca tutto in
puro decisionismo, ma che le scelte siano pesate.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
18
9
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Organizzazioni funzionali e project-oriented
• Nel caso delle organizzazioni Funzionali si ha una connotazione
gerarchica, ma che coinvolge più livelli (è più complessa).
–
–
vi è una precisa definizione del line management (gerarchia)
lo staff è raggruppato per specializzazione
• In questo caso i progetti sono gestiti in fasi separate e la
comunicazione segue il flusso gerarchico della struttura
• Nelle organizzazioni Project Oriented, invece, il personale è
ridistribuito sulla base dei progetti e risponde al Project Manager del
progetto che raggruppa lo staff.
• Le divisioni sono di solito di servizio ed il referente resta il Project
Manager, che ha grande autonomia
Entrambi gli approcci, se seguiti pienamente, presentano problemi.
• Esistono matrici (dette, rispettivamente, deboli, bilanciate e forti) che
combinano caratteristiche dei due approcci per il miglio vantaggio di
progetto.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
19
FASE 1: ANALISI E PORTATA DI UN PROGETTO
PM nell’organizzazione funzionale
Da PMBOK - PMI
• Un progetto coinvolge staff di diverse funzioni per le rispettive attività
• Comunicazioni e decisioni seguono il line management (la gerarchia)
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
20
10
FASE 1: ANALISI E PORTATA DI UN PROGETTO
PM nell’organizzazione Project-Oriented
Da PMBOK - PMI
• ogni progetto ha il proprio staff
• Il project manager gode di maggiore autonomia e decide i ruoli nel progetto
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
21
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Weak-matrix (matrice debole)
Da PMBOK - PMI
• Seguono molto il profilo funzionale
• Il project manager è più un coordinatore (facilitator)
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
22
11
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Strong-matrix (matrice forte)
Da PMBOK - PMI
• Seguono molto il profilo delle organizzazioni project-oriented
• Project manager, a tempo pieno, con considerevole livello di autorità
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
23
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Balanced-matrix (matrice equilibrata)
Da PMBOK - PMI
• Il project manager non ha autorità assoluta sul progetto e sul suo
finanziamento
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
24
12
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Composite-matrix (matrice composita)
Da PMBOK - PMI
• un’organizzazione funzionale può creare un gruppo per progetto importante:
• avrà molte caratteristiche di un gruppo di progetto di un’organizzazione
project-oriented.
• personale di diversi reparti funzionali, dedicato a tempo pieno al progetto,
• svilupperà procedure proprie, potrà operare anche al di fuori della struttura
gerarchica standard
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
25
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Strutture organizzative e progetti
Da PMBOK - PMI
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
26
13
FASE 1: ANALISI E PORTATA DI UN PROGETTO
PMO e Project Manager
Molte strutture (soprattutto nelle strutture a matrice e in quelle orientate
ai progetti) sentono il bisogno di un PMO
PMO: Project Management Office (meglio Program Management
Office)
• Visione strategica dei progetti
• Coordinamento di più progetti correlati (es. risorse condivise)
• Individuazione metodologie, standard e migliori pratiche di PM
• Predisposizione modulistica e documentazione
• Gestione dei rischi (condivisi e specifici)
• Gestione centrale degli strumenti di project management
• Coordinamento della comunicazione
• Monitoraggio tempi e budget (generalmente a livello aziendale)
• Coordinamento degli standard di qualità
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
27
FASE 1: ANALISI E PORTATA DI UN PROGETTO
PMO vs Project Manager
Integrazione PMO e Project Manager
• Obiettivi ed esigenze diversi, comunque allineati alla strategia
comune
• PM responsabile di speifici deliverable nell’ambito del progetto;
PMO ha specifici incarichi secondo la visione aziendale e
gestisce modifiche di grande portata (programma)
• PM controlla le risorse del progetto; PMO ottimizza l’uso delle
risorse condivise
• PM gestise ambito, scheduling, costo e qualità dei prodotti dei
Work Package; PMO gestisce rischio e opportunità complessivi e
interdipendenza tra i progetti
• PM risponde dei progressi del progetto; PMO relazione
complessivamente
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
28
14
FASE 1: ANALISI E PORTATA DI UN PROGETTO
PMO e struttura organizzativa
• Può essere adottato in qualsiasi struttura organizzativa
• A volte si limita a fornire suggerimneti su regole e procedure, altre
autorizza (in questo caso generalmente delega la propria autorità ai PM)
• Il gruppo di progetto fa riferimento sempre al PM, a volte al PMO quando
si tratta di risorse condivise (in questi casi c’è preventivo accordo tra
PMO e PM)
• Nelle strutture fortemente gerarchiche e nell’organizzazione projectoriented, il PMO è una casella tra i PM e la direzione generale
• Nelle organizzazioni a matrice forte e nelle composite, il PMO è il
manager dei PM
• Nelle strutture a matrice debole e a matrice equilibrata il PMO non riporta
al direttore generale
• Se il PMO è presente, gestisce il sistema di Project Management. Il
piano di Project Management descrive come sarà utilizzato questo
sistema.
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
29
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Definizione dei ruoli in un progetto
… ovvero persone giuste al posto giusto…
• Il PM definisce i ruoli all’interno di un progetto. E’ una delle prime
fasi/scelte da affrontare
• Occorrono tatto e diplomazia, ma interessi del progetto
• due differenti approcci:
– il primo, orientato alle persone:
• richiede più tempo perché le persone si adeguino naturalmente al
progetto e si orientino verso i ruoli più congegnali, ma rafforza l’impegno
e la lealtà di gruppo;
– il secondo, l’approccio alla mansione:
• pone le esigenze del progetto prima di quelle delle persone e risulta più
efficace quando le scadenze sono a breve termine. Spesso con questo
approccio ci si deve preparare ad affrontare più momenti di crisi, poiché
solitamente le richieste temporali sono molto vincolanti e le persone
incontrano difficoltà, rendendo difficile lo sviluppo di lealtà di gruppo e
impegno.
• sebbene migliore, non sempre è possibile scegliere il primo approccio
• cercate sempre di selezionare le persone giuste, tenendo presente che
a ciascun membro del team tende in modo naturale ad assumere
specifici atteggiamenti
Ci sono sempre comportamenti come quelli descritti nella prossima slide
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
30
15
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Definizione dei ruoli
•
il coordinatore: persona che funge da coordinatore ed assume il compito di chiarire gli obiettivi
al gruppo e favorire il processo di decision-making collegiale. Spesso però non porta a termine la
discussione, delegando gli altri…
•
il docente: è la persona che seguirà più da vicino il processo di cambiamento, cercando di
agevolarlo (mediante azioni di formazione). In generale, comunque, è anche colui che si aspetta
la modifica immediata dei comportamenti da parte degli altri;
•
l’attuatore: trasforma le idee in azioni pratiche (o a volte definisce un vero e proprio piano di
dettaglio). Può capitare che si senta poi così coinvolto da risultare inflessibile e poco
tollerante sui risultati prodotti da altri;
•
il tecnicone: in genere si identifica con il tecnico vero e proprio, il problem solver tecnologico, per
•
il mediatore: è colui che comprende tutti gli altri e come interagire immediatamente. In genere,
esempio. In genere è creativo ma ha difficoltà a seguire strettamente il piano;
però, tende a perdere interesse nel progetto una volta che viene terminata la fase di
pianificazione;
•
chi si sente “parte del team”: generalmente queste persone incoraggiano e appoggiano gli
altri e sono piuttosto diplomatiche, anche se a volte tendono ad evitare conflitti a discapito del
progetto;
•
il controllore: chi controlla e valuta tutte le fasi e le attività del progetto. Potrebbe però non
•
l’ansioso: è la persona che cerca di fare in modo che il progetto sia completato nei tempi giusti
essere in grado di stimolare gli altri ed essere visto dal gruppo in modo negativo;
ma tende a fare tutto autonomamente ed in modo eccessivamente apprensivo.
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
31
Definizione dei ruoli
• Per stabilire bene il ruolo che una persona (voi compresi) può
avere in un team di progetto, sia per carattere, sia per capacità,
ponetevi (e ponete, se è il caso) alcune domande fondamentali e
le cui risposte vi forniranno l’orientamento corretto:
• Quali skill ha la persona?
• Ha conoscenze specifiche?
• Qual è la sua ultima esperienza di progetto? Cosa ne ha appreso?
• Si dedicherà a tempo pieno al progetto?
• Chi valuterà l’operato della persona?
• Come potrà comunicare se c’è un problema o informarvi in caso di
successo?
• Chi si occuperà delle esigenze dei componenti del gruppo di
progetto?
• Qual è la situazione operativa ottimale per ciascuna persona?
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
32
16
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Il Project Charter (1)
• Autorizza formalmente il progetto
• È pubblicato da un iniziatore o sponsor del progetto (esterni al
progetto)
• È prodotto tenenedo in considerazione:
–
–
–
–
–
–
Richieste di mercato
Necessità commerciali
Richieste di un cliente
Miglioramento tecnologico
Requisito legale
Esigenza sociale
• Definisce come rispondere e quali progetti autorizzare ed avviare
formalmente. I metodi di selezione dei progetti comportano la
misura del valore o del grado di interesse per lo sponsor
• Prende spunto dallo studio di fattibilità (a volte analisi più semplici)
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
33
FASE 1: ANALISI E PORTATA DI UN PROGETTO
Il Project Charter (2)
Deve fornire le informazioni:
– Requisiti che soddisfano le esigenze, le necessità e le
aspettitative
– Necessità commerciali, descrizione del progetto ad alto livello o
requisiti del prodotto
– Obiettivo e giustificazione del progetto
– Project manager assegnato e livello di autorità
– Scheduling delle milestone di riepilogo
– Influenza degli stakeholder
– Organizzazioni funzionali e loro partecipazione
– Assunti organizzativi, ambientali ed esterni
– Vincoli organizzativi, ambientali ed esterni
– Business Case che giustifica il progetto (compreso il rendimento
dell’investimento)
– Budet riepilogativo
• Spesso si ricorre al parere di esperti
Prof. R. Folgieri, Ing. PhD – Gestione e Organizzazione dei Progetti
34
17