Project Management

UNIVERSITA’ DEGLI STUDI DI TRENTO
FACOLTA’ DI ECONOMIA

Corso di LS in Net Economy: Tecnologia e Management dell’informazione e della
conoscenza
Anno Accademico 2008-2009

Progettazione di un sistema automatico per la creazione e
somministrazione di questionari

Corso di Project Management

Docente: Dott. Loris Gaio
Studente: Nicola Cerami 131158

Nicola Cerami 131158 Project Management

Sommario
Introduzione ......................................................................................................................................... 3
Natura e caratteristiche del progetto ................................................................................................... 4
Obiettivi ........................................................................................................................................... 4
Risorse e Vincoli .............................................................................................................................. 4
Stakeholder e oppositori................................................................................................................... 5
Procedure e metodi........................................................................................................................... 6
Work Breakdown Structure ............................................................................................................. 7
Aspetti di Valutazione.......................................................................................................................... 9
La Valutazione Economica .............................................................................................................. 9
La Valutazione Finanziaria ............................................................................................................ 11
La Valutazione del Rischio ............................................................................................................ 12
La Pianificazione e la Programmazione............................................................................................. 13
Il Contesto Organizzativo e il Controllo ............................................................................................ 14
Conclusioni ........................................................................................................................................ 15
Appendice .......................................................................................................................................... 17
Fig. 1- Stakeholders ................................................................................................................... 17
Fig. 2- Modello a Spirale ........................................................................................................... 17
Fig. 3- Work Breakdown Structure: Primo Livello di Scomposizione Progetto ....................... 18
Fig. 4- Work Breakdown Structure: Secondo Livello di Scomposizione .................................. 18
Fig. 5- Work Breakdown Structure: Scomposizione Analisi Preliminare ................................. 18
Fig. 6- Work Breakdown Structure: Scomposizione I Ciclo ..................................................... 19
Fig. 7- Work Breakdown Structure: Scomposizione II Ciclo .................................................... 19
Fig. 8- Work Breakdown Structure: Scomposizione III Ciclo................................................... 19
Tab. 1-Work Breakdown Structure Table .................................................................................. 20
Tab. 2- Costi del Personale espressi in ore/uomo ...................................................................... 21
Tab. 3- Costing su Work Breakdown Structure ......................................................................... 22
Fig. 9- Diagramma di GANTT ( presentato diviso per cicli di vita per leggibilità) .................. 25
Tab. 4- Attività (Tempi espressi in giorni) - “Valutazione Temporale task e sequencing” ...... 26
Fig. 10- Grafo AON ................................................................................................................... 26
Tab.5 - Program Evaluation and Review Technique ( PERT ) .................................................. 27

2


Introduzione
Il presente documento di pianificazione tratta del management di un progetto per lo sviluppo di
un sistema automatico ( applicativo Software ) per la creazione e somministrazione di questionari
per un uso interno all’organizzazione di riferimento.
La selezione di questo progetto è avvenuta sotto suggerimento del Project Manager e dei
Ricercatori secondo un approccio non numerico, in particolare l’approccio Sacred Cow. Inoltre si è
ritenuto necessario tale applicativo software per ottimizzare l’efficienza dell’impiego delle risorse
(in particolare Risorse Umane), pertanto combinando due approcci non numerici: Sacred Cow e
Ampliamento attività.
Nel prossimo capitolo sarà fornito in dettaglio il progetto nelle sue intenzioni principali, mentre
in questa introduzione verrà esposto il contesto aziendale per il quale questo sistema automatico è
proposto.
La Fondazione Bruno Kessler, la quale è situata in Trentino, Provincia Autonoma e statuto
speciale nel nord Italia, svolge attività di ricerca principalmente negli ambiti delle Tecnologie
dell’Informazione, dei Materiali e Microsistemi, degli studi Storici italo-germanici e delle Scienze
Religiose. In questo documento verrà trattata solo la divisione TCC che svolge attività di ricerca
nell’ambito dell’elaborazione del linguaggio e dello sviluppo di interfacce intelligenti multimodali,
multilingue, specifiche per l’utente e tecnologie basate sulla conoscenza contestuale e semantica.
Gli obiettivi che si propone la divisione sono:
• Interazione uomo-uomo e uomo-macchina, enfatizzando sia la multi modalità e l’approccio
multilinguistico, sia l’interazione con l’ambiente virtuale e reale.
• Rappresentazione flessibile dell’informazione multimediale, fatta su misura per l’utente e lo
specifico contesto d’uso.
• Analisi automatica di testi quali documenti, e-mail o pagine web ed estrazione automatica di
informazione dagli stessi.
Il progetto da realizzare tratta l’introduzione di un sistema software per l’uso interno alla
divisione Tecnologie cognitive e della comunicazione (che chiameremo TCC d’ora in poi)1:
divisione della Fondazione Bruno Kessler2, in particolare per i Ricercatori. Si intende specificare in
questa sede che la divisione TCC presenta una grande esperienza nel trattare questa tipologia di
progetti, come specificato dagli obiettivi della divisone.

1
http://www.itc.it/irst/Renderer.aspx?targetID=164
2
http://www.fbk.eu/it
3


Nei prossimi capitoli si presenta una descrizione degli obiettivi del progetto e dei limiti attuali
all’interno della divisione, la descrizione degli Stakeholder ed eventuali oppositori coinvolti per poi
passare, successivamente, ad una valutazione economica e del rischio allo scopo di verificare la
fattibilità del progetto. Quindi si prosegue con la gestione delle attività e con lo studio delle
tempistiche per svolgere il progetto. Infine viene effettuata la definizione, la stima e l’allocazione
delle risorse necessarie e si conclude con i metodi di pianificazione e controllo previsiti.

Natura e caratteristiche del progetto
Come già riportato, il progetto ha tutte le caratteristiche che fanno di esso un progetto interno volto
a migliorare alcuni aspetti relativi all’interno della divisione.
Nei seguenti paragrafi si considerano gli obiettivi, i vincoli imposti e successivamente gli
stakeholders e gli eventuali oppositori del progetto, in modo tale da essere certi di tenere nella
giusta considerazione tali elementi durante le fasi della progettazione. Infine si analizzeranno
procedure e metodi utilizzati nella pianificazione di questo progetto, nonché la Work BreakDown
Sctructure.

Obiettivi
Il progetto di cui si occupa questo elaborato è la progettazione e sviluppo di un sistema
informatico per la costruzione di questionari sia cartacei che online tramite interfaccia grafica. Si
tratta di un’applicazione Web, a cui gli utenti accedono tramite un Web Browser, quest’ultimo un
programma in grado di interpretare il codice HTML (Hypertext Markup Language) e visualizzarlo
in formato di ipertesto.
Lo scopo di questo sistema è ovviare ad alcuni limiti delle più tradizionali modalità di
costruzione, tramite strumenti quali Word, Excel, ed alla semplice somministrazione del
questionario in formato cartaceo. Si intende realizzare questionari con semplicità e velocità,
eseguire un’analisi in tempo reale del processo di avanzamento del questionario, ed aumentare la
rapidità di trasferimento ed elaborazione dei dati.

Risorse e Vincoli
Per la realizzazione di questi sistema software dobbiamo considerare alcuni vincoli imposti dal
management. In particolare le risorse sono vincolate a livello di risorse umane. Infatti il Project
Manager ha stabilito che le persone che lavoreranno al progetto sono nove. Verranno illustrati nel
paragrafo relativo agli stakeholder. In particolare cercheremo di bilanciare l’utilizzo delle risorse in

4


modo da mantenere il progetto entro i tempi previsti (6 mesi) senza crashare il più possibile in
modo da lasciare alle risorse umane periodi liberi in cui occuparsi delle proprie mansioni ordinarie.
Il team di progetto è formato dal Project Manager, un’Analista, uno Psicologo Cognitivo, un
Grafico Creativo, uno Sviluppatore Software e quattro Ricercatori della divisione, quest’ultimi per
applicare una progettazione centrata sull’utente. Tale scelta è dovuta al fatto che in divisione si
eseguono una moltitudine di progetti e le risorse umane disponibili e programmabili per tale periodo
a disposizione sono queste. Inoltre sono i dipendenti con maggior esperienza nella divisione e i
Ricercatori (in particolare 4) sono stati selezionati dal Project Manager come key Users per la
progettazione dell’applicativo software.

Stakeholder e oppositori
Comprendere gli Stakeholder è l’elemento chiave di molti approcci relativi al rilevamento dei
requisiti, perché in un’organizzazione non è semplicemente l’utente finale a essere influenzato
dall’introduzione di una nuova tecnologia. Infatti il punto di partenza è l’identificazione degli
Stakeholder.
Uno stakeholder può essere definito come una persona alla quale stanno a cuore il successo o il
fallimento del sistema. Può essere utile distinguere categorie diverse di stakeholder:

• Stakeholder primari: sono le persone che effettivamente usano il sistema, cioè gli utenti
finali (nel nostro caso, i ricercatori/sperimentatori).

• Stakeholder secondari: le persone che non usano direttamente il sistema, ma da esso
ricevono l’output oppure gli forniscono l’input (i soggetti/rispondenti).

• Stakeholder terziari: le persone che non rientrano in nessuna delle prime due categorie, ma
che sono direttamente influenzate dal successo o dal fallimento del sistema (General Manager,
Project Manager; ad esempio per un aumento della produttività, per una riduzione dei tempi di
lavoro, ecc.).

• Stakeholder agevolanti: le persone che sono coinvolte nella progettazione e manutenzione
del sistema (Ingegnere informatico, esperto di interaction design, nel nostro progetto i Grafici
Creativi e gli Sviluppatori Software).

Lo scopo della progettazione è soddisfare i bisogni del maggior numero possibile di stakeholder.
Nel caso in cui le esigenze degli stakeholder entrino in conflitto tra di loro, sì da priorità ai requisiti
degli stakeholders di categoria più alta, in questo progetto, gli sperimentatori e gli utenti finali

5


(definiti Soggetti d’ora in avanti quest’ulltimi) che andranno anche loro ad utilizzare il sistema per
la compilazione del questionario online.

Il semplice schema in appendice (fig. 1) mostra gli stakeholders del progetto.

Inoltre il sistema verrà utilizzato anche dai soggetti sperimentali per completare questionari on
line durante gli esperimenti effettuati dai ricercatori della divisione, quindi anche loro portatori
d’interesse e, di conseguenza, considerati all’interno del progetto.

Procedure e metodi
L’approccio scelto alla progettazione e sviluppo del sistema, essendo un progetto innovativo, è
stato il modello di ciclo di vita a spirale (vedi appendice fig. 2). Tale modello è tipico di
procedimenti di sviluppo che partono da un prototipo. Esso inizia con l’individuazione degli utenti e
dei compiti che essi svolgono per raggiungere l’obiettivo finale (il questionario definito), per poi
sviluppare l’analisi dei requisiti, compito che poi si tradurranno in funzionalità che il sistema dovrà
supportare. A partire da queste ultime, iniziano una serie di cicli di
implementazione/valutazione/produzione di nuovi requisiti, fino ad arrivare al prototipo operativo
attraverso l’implementazione di prototipi.
In particolare pianificheremo tre cicli che verranno trattati separatamente nelle successive fasi di
analisi al fine di semplificare il più possibile le problematiche che potremmo incontrare in questo
frangente e, in particolare, per una migliore pianificazione del controllo, fase che vedremo in
dettaglio nell’ultimo capitolo.
Definito il modello vitale del nostro progetto, consideriamo quali saranno le procedure ed i
metodi che andremo ad utilizzare al fine di definire il piano di progetto stesso nei suoi vari aspetti.
Il punto focale della nostra analisi è la Work Breakdown Strcture (denominata d’ora in avanti
WBS), al quale è dedicata il paragrafo successivo. Da essa svilupperemo la valutazione del progetto
secondo le due classiche dimensioni: economica e del rischio. A tal proposito è dedicato l’intero
capitolo 3. Per quanto riguarda la valutazione economica seguiremo un approccio di costing di tipo
top-down, mentre il rischio sarà valutato esplicitando i fattori di rischio. La terza dimensione
(finanziaria) non verrà trattata in questo progetto, la cui motivazione si rimanda al capitolo 3.
La pianificazione sarà effettuata a partire da un’analisi del percorso critico (vedi Grafo AON
figura 10), costruendo inoltre un Diagramma di Gantt (Figura 9 ). Inoltre si utilizzerà il metodo per
stime probabilistiche, vale a dire il Program Evaluation and Review Technique (denominato PERT,
consultabile in appendice, tabella 5 ).

6


Per quanto riguarda il controllo, come già anticipato, non possiamo che rimandare al capitolo 5,
a cui rimandiamo al capitolo.
Il presente progetto si considera concluso con il prototipo operativo, vale a dire con
l’implementazione effettiva del sistema automatico per la creazione e somministrazione di
questionari. Dopo di ciò nessun altro tipo di attività è previsto all’interno del progetto pertanto si
riterrà concluso e non verranno considerati eventuali sviluppi futuri , integrazioni al sistema e la
fase di manutenzione del sistema in quanto non rientranti negli obiettivi del management.

Work Breakdown Structure
La metodologia utilizzata per giungere ad una WBS efficace e funzionale è quella standard ed, in
particolare, essa è stata redatta secondo un approccio top-down procedendo per scomposizione dai
problemi maggiori, stilando pertanto le fasi principali (definite deliverables). La scelta di tale
approccio dipende dal fatto che l’approccio top-down non richiede una conoscenza a priori del
sistema, della sua architettura e delle sue componenti ( è proprio il nostro caso). Inoltre prende in
considerazione aspetti generali e comuni quali l’integrazione, la configurazione, la documentazione,
ecc. Tale approccio può sottostimare i costi di soluzione e coordinamento di particolari aspetti di
dettaglio di natura tecnica.
La WBS è rappresentata graficamente in appendice (fig. 3,4,5,6,7,8). Inoltre nell’appendice è
consultabile la Work Breakdown Structure Table (tab. 1).
La prima sezione riguarda la fase di Analisi Preliminare che si stima necessiterà in totale di
2,75 giorni (si approssima per eccesso a 3 giorni lavorativi) e che comprende la Pianificazione dei
requisiti e l’Analisi di Fattibilità Preliminare. Inizialmente è fissata una riunione preliminare ( di
durata 2 ore ) con il Project Manager, l’Analista e i quattro Ricercatori considerati all’interno della
divisione. In tale sezione il Project Manager è incaricato di definire quali debbano essere i risultati
attesi, quale sia lo scopo primario di progetto, l’utenza alla quale l’applicazione sarà destinata (già
nota), le risorse per raggiungere gli obiettivi previsti e i tempi di consegna. Dopo questa sotto fase
l’Analista si soffermerà a stilare e formalizzare i requisiti preliminari emersi (8 ore o 1 giorno). Una
volta che l’analista ha formalizzato i requisiti preliminari il Project Manager provvederà alla sua
validazione (8 ore). Terminati questi work package si passa all’Analisi di Fattibilità Preliminare:
analisi effettuata dal Project Manager, l’Analista e lo Sviluppatore. Una volta terminata
positivamente la prima sezione si inizia la seconda parte del lavoro, vale a dire il I Ciclo, il quale si
stimi durerà 52,25 giorni (approssimando per eccesso 53 giorni lavorativi). Tale ciclo è diviso in
cinque sotto-attività: Analisi Requisiti, Design, Implementazione, Integrazione/Testing e

7


Documentazione. La fase di Analisi dei Requisiti (2,25 giorni 2,5 giorni) inizia con un
BrainStorming (durata 2 ore) a cui partecipano tutti gli esperti del team di progetto per far emergere
delle idee per risolvere il problema in questione, nonché esplicitare le esigenze del utente finale (
Ricercatore). Successivamente l’Analista provvederà ad effettuare interviste mirate (2 ore) ai
Ricercatori (si considererà anche il metodo Delphi), in modo tale da stilare requisiti sempre più
aderenti alle aspettative degli stakeholders. Una volta ultimata l’intervista, l’Analista provvede a
stilare e formalizzare i requisiti (8h) per poi passare al Project Manager il compito di validare i
requisiti fino ad ora stilati (8h). Terminata la fase di analisi di requisiti si passa alla fase di Design
(14 giorni) dove qui si prevede che l’unica risorse coinvolta ( si parla sempre di risorse umane
sempre) sia il Grafico Creativo. Tale fase prevede la progettazione dell’architettura logica (4
giorni), dell’architettura fisica (1 settimana lavorativa) e ,infine, dell’architettura strutturale (1
settimana).
A questo punto si inizia con l’Implementazione (15 giorni), effettuata dallo Sviluppatore
Software, la quale comprende la creazione del codice HTML (1 settimana), l’implementazione del
primo prototipo (1 settimana) e, infine, la creazione dei contenuti del primo prototipo (1 settimana).
Una volta implementato il primo prototipo si passa alla fase di Integrazione/Testing (19 giorni).
Tale fase risulta esser la più critica in un progetto di questo tipo, infatti è stato pianificato un tempo
per questa fase largamente abbondante: stima realizzata in base a dati storici ed esperienza
pluriennale del team di progetto. Questa fase include la presenza di uno Psicologo Cognitivo
presente nella divisione TCC esperto di valutazioni sommative, vale a dire valutazioni di usabilità,
di accessibilità, interazioni con l’interfaccia del prototipo,ecc. Inizialmente viene effettuato un
Alpha Testing (6 giorni), vale a dire un testing effettuato all’interno della divisione TCC, in
particolare con i Ricercatori coinvolti nel progetto. In secondo luogo viene programmato anche un
Beta Testing (10 giorni) per l’esterno della divisione, vale a dire con i Soggetti che andranno a
compilare effettivamente i questionari on line. Tali soggetti sono sempre facilmente disponibili
all’interno dell’organizzazione. Si tratta di personale dipendente e, solitamente, di studenti,
tirocinanti, tesisti e dottorandi presenti all’interno dell’organizzazione. Si stima un testing beta su
10-15 soggetti. Una volta ultimati i due test lo Psicologo Cognitivo somministra un questionario di
valutazione (cartaceo) sia ai Soggetti sia ai Ricercatori per la raccolta e analisi dei dati fin qui
ottenuti.
Parallelamente all’Integrazione/Testing, dato che le risorse necessarie non sono vincolate, viene
svolta anche l’attività di Documentazione (21giorni), soltanto dopo che la fase di Implementazione
sia terminata. Tale fase è svolta dall’Analista, dal Grafico Creativo, dallo Sviluppatore e dal Project

8


Manager, quest’ultimo con il compito di supervisionare e validare tali documenti. Essa si suddivide
in documentazione specifiche tecniche (3 giorni) dove vengono stilati e formalizzati i requisiti
funzionali, i requisiti non funzionali e le specifiche tecniche, il Manuale Utente (2 giorni) e, infine,
la Documentazione di Progetto, il tutto validato dal Project Manager. Quest’ultima si è ritenuta
necessaria e fondamentale anche per un tentativo di privilegiare e “sponsorizzare” economie di
replicazione all’interno dell’organizzazione, soprattutto in ambito di questi progetti, spesso soggetti
a fallimenti. Inoltre è fondamentale per stabilire se continuare o meno con la prosecuzione del
progetto stesso.
Come detto in precedenza, a partire da questo I Ciclo, iniziano una serie di cicli di
implementazione/valutazione/produzione di nuovi requisiti, fino ad arrivare al prodotto finale
attraverso l’implementazione di prototipi. I restati due cicli sono praticamente uguali al primo salvo
il fatto che nel secondo ciclo si parla di affinamenti mentre nel terzo ciclo si parla di definizione e
prototipo operativo.

Aspetti di Valutazione
La necessità di una Valutazione secondo le tre dimensioni fondamentali (economica, finanziaria
e del rischio) è fondamentale per stabilire la fattibilità o meno del progetto in questione. Sono
dunque necessari strumenti per valutare anche la rischiosità delle attività che si compiono.
Prima di passare alla valutazione economica è opportuno ricordare che l’obiettivo del progetto
non è prettamente economico; naturalmente uno sviluppo di questo sistema potrà generare dei
vantaggi all’interno della divisione TCC, quali ad esempio una riduzione dei tempi di raccolta ed
analisi dei dati da parte dei Ricercatori.
Quindi, la condizione fondamentale affinché questo progetto non risulti fallimentare dal punto di
vista della valutazione è quella di avere a fine progetto un sistema funzionante per i Ricercatori
della divisione, vale a dire un prototipo operativo.
Vediamo ora in dettaglio la valutazione economica.

La Valutazione Economica
Dato il numero elevato ma gestibile di attività che risultano dalla WBS e la bontà di questa a
livello di fattibilità di un’analisi dei costi tramite approccio bottom-up, si propende per questo tipo
di analisi, in modo tale da determinare il costo totale del progetto per aggregazione dei vari work
package. Un’analisi dei costi secondo l’approccio top-down è stata scartata data la complessità dei

9


deliverables presenti all’interno dello stesso progetto, oltre ad una difficoltà a reperire dati storici di
questo tipo per effettuare stime previsionali corrette.

Tale analisi è suddivisa in due sezioni, quella riguardante i costi fissi e quella riguardante i costi
variabili.

I costi fissi sono solitamente suddivisi in tre grandi categorie in base alla portata del progetto,
vale a dire risorse umane (lavoro), materiali e altre risorse. Essa viene valutata studiando il profilo
temporale che dovrebbe occupare per la realizzazione.

E’opportuno specificare che i costi fissi relativi ai materiali e altre risorse non vengono
considerati, in particolare i costi generali riguardanti le spese di affitto, di amministrazione, di
manutenzione degli strumenti informatici e non solo, di consumi di rete e comunicazione, di servizi
accessori e di risorse condivise ( mensa, biblioteca, sale riunioni, ecc). Tra questi figurerebbero
anche i costi di materiali di cancelleria. Tali costi fissi non vengono considerati per il fatto che sono
già presenti e già stati sostenuti all’interno dell’organizzazione, quindi non considerati in questo
progetto.

Fra i costi fissi per un progetto della durata di quello in esame fanno parte, come già anticipato,
anche i costi variabili, i quali riguardano invece solo e unicamente i costi diretti delle risorse umane,
ovvero le ore di lavoro del team di progetto non considerando gli oneri sociali e assicurativi. Anche
nei costi variabili andrebbero considerati i costi dell’hardware e dei software acquisiti, i costi di
logistica e formazioni (non pianificati in questo contesto perché non ritenuto necessario dal Project
Manager) ma per le stesse motivazioni dei costi fissi menzionati precedentemente non verranno
considerati in questo progetto. Pertanto l’idea è quella di considerare unicamente i costi diretti del
personale, il quale è sicuramente il fattore unico dominante.

In Appendice è riportata la tabella di riferimento (tab. 2) per il calcolo della remunerazione
espressa in ore/uomo del personale tecnico impiegato.

Come anticipato il Budgeting è stato effettuato su Work Breakdown Structure tramite l’approccio
bottom-up. Il primo passo da compiere è quello di dare un costo ad ogni attivià procedendo
all’assegnazione di costi per le risorse.

In appendice si mostrano i tabulati relativi a tale procedimento (tabella 3_Costing su WBS).

10


Fatto ciò, procediamo al calcolo dei totali di interesse, nello specifico i subtotali relativi ad ogni
ciclo di sviluppo nonché i costi totali. Nello specifico il costo totale del progetto, in termini di
risorse umane, è di 25.180 Euro. Tale analisi ci mostra che il progetto è fattibile dati i vincoli
imposti dal management in quanto la durata totale del progetto è stimata largamente inferiore
all’anno ( 6 mesi). Inoltre si può notare dall’allegato in appendice il costo di ogni deliverables. In
particolare per la fase di Analisi Preliminare è previsto un costo di 700 Euro di Personale, mentre
per i tre cicli è stato stimato lo stesso costo per ognuno: 8160 Euro.

Nei cicli successivi al primo sono stati stimati tempi, risorse e, di conseguenza, costi uguali per
tutelare il progetto. Tale comportamento è derivato dalla astensione al rischio del Project Manager.
Infatti in realtà è previsto un decrescere dei tempi da un ciclo all’altro fino all’implementazione del
prototipo operativo. Tale scelta è stata presa dal Management per tutelarsi contro il rischio di
fallimento del progetto, oltre al fatto che dopo il primo ciclo è possibile valutare se procedere o
meno con il progetto (quindi danno limitato in termini di tempi e costi delle risorse umane nel caso
di fallimento del progetto).

Il progetto si prevede che inizierà effettivamente il 12 Gennaio 2009 e si prevede venga concluso
per mercoledi 15 Luglio ( 6 mesi ). Nel capitolo relativo alla pianificazione e programmazione delle
attività vedremo quale sarà, oltre al tempo stimato (stimato e previsto tramite le tecniche di
Brainstorming e i dati storici del passato, in particolare l’esperienza del team di progetto nel gestire
progetti software) il tempo pessimistico di progetto, il tempo maggiormente atteso e il tempo
ottimistico.

Ora che abbiamo una base sulla quale lavorare è il caso di passare alla parte relativa alla
valutazione finanziaria.

La Valutazione Finanziaria
In questo progetto non è possibile analizzare la valutazione finanziaria in quanto non si è in
grado di calcolare il Valore Attuale Netto (VAN) per il fatto che non vi sono dei flussi di cassa
netti, vale a dire entrate meno uscite. In questo caso e, come specificato precedentemente, si tratta di
un applicativo software per uso interno. Per tale motivo non ha senso stimare il tasso di rendimento
interno non potendo appunto stimare i flussi d’entrata in quanto non esistenti.

11


La Valutazione del Rischio
Nella realizzazione di questo progetto è possibile incorrere in una serie di rischi che potrebbero
compromettere l’intera o parziale riuscita del progetto stesso. Per questo motivo è importante
identificare i fattori di rischio ed attuare manovre di prevenzione.
Analizziamo nel presente paragrafo le modalità di valutazione del rischio del progetto
esplicitando le nostre scelte.
Un possibile fattore di rischio è la realizzazione di un sistema non idoneo o a capacità limitata
rispetto alle esigenze dei Ricercatori. Tra gli altri possibili rischi in questa tipologia di progetto ci
sono senz’altro le scadenze, i costi (stime e previsioni irragionevoli), e in particolare i requisiti che
possono essere non corretti, incompleti, incoerenti e volatili. A tal proposito il Project Manager ha
scelto nella fase iniziale del progetto un’ottima forma di pianificazione per il ciclo di vita dello
stesso (modello a spirale), in modo tale da effettuare un processo iterativo fino a stilare requisiti via
via sempre più precisi e definiti e che rispondano soprattutto alle esigenze dell’utente finale ( in
particolare i Ricercatori e i Soggetti). Tale analisi è fondamentale per assistere la pianificazione
nella realizzazione del budget e nella programmazione delle attività (tempi). In questo progetto
vieni infatti pianificata un’Analisi preliminare, in modo tale da coinvolgere l’intero team di progetto
in questo processo. Tramite le tecniche di Brainstorming, interviste e soprattutto tramite una
valutazione ciclica da parte di uno Psicologo Cognitivo si cerca di monitorare e controllare i fattori
di rischio. Elevato Monitoraggio e comunicazione pianificato dal management tra gli stakeholder
coinvolti.
Concludendo quest’aspetto, un’altra tipologia di rischio può essere rappresentata dal numero di
risorse umane inadeguato al progetto. Nello specifico il numero stimato di risorse umane coinvolte
nel progetto risulta esser più che soddisfacente, in particolare per le loro grandi competenze ed
esperienze. C’è però il rischio, ad esempio, che l’Analista (ma non solo: Project Manager, Psicologo
Cognitivo, Grafico Creativo e Sviluppatore), nel suo periodo di attività pianificato risulti indisposto
per tale periodo. In tale condizioni il management ha deciso di sospendere l’attività del progetto per
i giorni necessari al recupero della figura professionale di interesse in quanto non è stato ritenuto
vantaggioso inserire in questo caso altre risorse umane in quanto non disponibili. Il Project Manager
inoltre ha valutato la possibilità di inserire eventualmente tirocinanti o tesisti all’interno del progetto
in corso d’opera. Valutazione non presa in considerazione in quanto fonte di rischi ancor maggiori
per via della loro poca conoscenza del dominio, soprattutto, in fase avanzata del progetto.
Si è ritenuto, essendo un progetto esclusivamente interno, di appunto sospendere in tali casi il
progetto per il periodo necessario. Eventuali ritardi in questo senso non sono poi cosi preoccupati
12


per il management, in quanto gli altri stakeholders possono dedicarsi alle proprie attività routinarie
nel frattempo.

La Pianificazione e la Programmazione
L’attività di programmazione e di pianificazione ha il preciso obiettivo di rendere evidente un
eventuale ritardo del progetto e quindi di stimolare eventuali azioni correttive, in modo da
soddisfare gli obiettivi di qualità, tempi e costi previsti a inizio progetto. Dal punto di vista
programmatico il progetto è stato diviso logicamente in quattro parti, ognuna corrispondente ad un
ciclo del modello di sviluppo a spirale. Ogni ciclo è quindi trattato separatamente dal punto di vista
programmatico in modo da aiutarci ad evitare procedure troppo complesse e di difficile
applicazione. E’ fondamentale tener presente che ogni ciclo dipende dal precedente in sede di
programmazione temporale dei task. Pertanto ancora una volta procediamo partendo dalla nostra
WBS.
Sono stati creati alcuni diagrammi che a tale scopo, favoriscono la pianificazione e la
programmazione del progetto stesso. Come primo strumento su può notare il diagramma di Gantt
(Figura 9), dove si rappresenta la distribuzione temporale delle varie attività di progetto.
Dal diagramma di Gantt è stato possibile ricavare la tabella di valutazione temporale task e
sequencing delle attività individuate che vanno a formare il progetto (Tabella 4). A questo punto è
possibile individuare quali siano le attività che devono essere completate affinchè altre possano
iniziare. Per comprendere al meglio le attività coinvolte si presenta il diagramma AON (Figura 10)
Come si può notare dal diagramma sono tutte attività sequenziali a parte la fase di
integrazione/testing che può iniziare assieme all’attività di documentazione in quanto non sono
attività vincolate dalle stesse risorse, ma possono partire solo e solo se l’attività di Implementazione
viene terminata (milestone). Il sentiero risultante in questo progetto è uno soltanto (critico) ed è
stato individuato dalla sequenza di attività ABCDEFGHIJKLMNOPQ. Essendo un sentiero critico
si può affermare che un ritardo nell’esecuzione di una delle attività comporterebbe un ritardo
dell’intero progetto. E’quindi importante tenere controllata la durata di queste attività ai fini del
rispetto dei tempi previsti e, non solo, per l’applicabilità e prosecuzione naturale del progetto.
Il Project Manager ritiene auspicabile che il progetto sia portato a termine in 6 mesi dal giorno di
inizio dell’attività di pianificazione preliminare. Questo periodo di tempo può essere stimato in
circa 163 giorni lavorativi. Dal momento che si suppone che la distribuzione si approssimi ad una
normale standardizzata, la probabilità che questo avvenga è del 67,72%, vale a dire circa il 68%,
come si può notare in tabella 5 e nel relativo allegato. Inoltre, sempre consultabile in allegato, è
13


stata calcolata la probabilità di terminare il progetto prima di 170 giorni. Tale valore è risultato del
97,67%.
Una possibile soluzione è destinare più risorse alle attività di design, implementazione e Testing,
ma come già largamente anticipato queste sono le uniche risorse a disposizione della divisione TCC
disponibili nell’arco di tempo considerato, nonché le più competenti in questo dominio. Per non
specificare anche il fatto che i tempi di queste fasi sono stati stimati largamente abbondanti.
La stima delle durate proviene da giudizi di esperti (il team), i quali sono abituati a lavorare per
progetti e conoscono molto bene l’ambiente e il dominio di riferimento, oltre a previsioni e dati
storici provenienti dal centro di Ricerca.
Evitiamo in questa sede di riportare tutte le considerazioni che sono state fatte relativamente
all’assegnazione del lavoro, si noti comunque che tutte le scelte sono conseguenze delle
informazioni che avevamo dai procedimenti descritti precedentemente: il team di progetto cosi
costituito.

Il Contesto Organizzativo e il Controllo
Nonostante il Project Manager svolga un’attività di controllo durante l’intera durata del progetto,
è necessario stabilire dei punti di controllo (milestone), durante i quali verrà accertato lo stato di
avanzamento del progetto in termini di qualità, costi e tempi. Questi punti di controllo
coincideranno con i termini di conclusione delle attività. Si possono a questo punto inserire tre
milestone fondamentali nel nostro progetto. Uno al termine dell’attività di Analisi Preliminare, uno
al termine del Primo Ciclo e uno al termine del Secondo Ciclo.
Per controllare al meglio il fattore temporale bisogna porre attenzione sulle attività del sentiero
critico, dato che sono quelle che potrebbero ad un inevitabile aumento dei tempi di realizzazione del
progetto ed un conseguente aumento dei costi in termini di risorse umane impiegato. Qui ogni
attività è critica quindi va continuamente controllata e monitorata.
La programmazione di una fase di manutenzione del sistema non verrà considerata in questa
sede perché esula dal progetto in questione. Va comunque precisato che all’interno della FBK è
presente uno staff tecnico addetto proprio alla gestione e risoluzione di queste tematiche e
problematicità.
Ricordiamo brevemente il tipo di progetto del quale ci stiamo occupando: si tratta di un progetto
innovativo che mira a produrre un prototipo operativo funzionante di un applicativo software per la
costruzione di questionari sia cartacei che online tramite interfaccia grafica.

14


L’approccio più adatto per un progetto di tale tipo è un approccio che prevede il massimo grado
di flessibilità. Mentre il progetto prosegue, gli obiettivi possono necessitare di essere ridefiniti. Tale
approccio come sappiamo è divisionale se il grado di novità è elevato. Dobbiamo quindi istituire un
sistema di controllo che preveda il confronto tra costi del progetto stesso e i bisogni che emergono
nel tempo, in modo da evitare disallineamenti e conseguenti problemi.
Il limitato utilizzo di risorse umane ci pone nella situazione favorevole per attuare un controllo
abbastanza stretto dell’operato delle stesse. Inoltre alla fine di ogni ciclo prototipale vi è infatti un
momento di documentazione.
Inoltre l’obiettivo finale è chiaro da subito ed è improbabile che il progetto sia ridirezionato
verso altri obiettivi in corso d’opera. Molte maggiori sono le probabilità di vedere il progetto
annullato a causa della scarsità di risultati dopo un ciclo di vita. Questo modello di controllo ci
permette comunque di limitare i danni in caso di insuccesso non dovendo attendere la fine del
progetto ed il conseguente esborso dell’intero budget in caso di fallimento (si parla in caso di
fallimento al primo ciclo di una perdita totale di 8860 Euro in termini di risorse umane).
Il ciclo di più difficile completamento è palesemente quello relativo alla creazione del primo
prototipo, ovvero quello maggiormente pregno di contenuti innovativi.

Conclusioni
Il documento di pianificazione presentato mira ad analizzare e chiarire al meglio la natura e le
caratteristiche del progetto. Quanto fatto analizza il progetto sotto molti aspetti utilizzando
strumenti d’analisi e grafici che forniscono informazioni importanti al fine di portare a termine nel
migliore dei modi il progetto, vale a dire soddisfare gli obiettivi richiesti. Tuttavia, in particolare
nelle fasi iniziali ma non solo, emergeranno quasi certamente problemi che non sono stati
considerati nonostante si sia cercato di anticipare e prevedere i possibili fattori di rischio. Pertanto
sarà compito del Project Manager e del team di progetto che in base alle loro abilità ed esperienze
dovranno essere in grado di gestire e risolvere eventuali problemi e/o conflitti riscontrati di volta in
volta.
In conclusione, è stato deciso dal Project Manager con i suoi collaboratori, che tale progetto sarà
realizzato a partire dalla data pianificata (12/01/2009) specificando che l’organizzazione e
schedulazione delle attività non sono garanzia assoluta di riuscita del progetto. Rispetto ai tempi
stimati la percentuale di riuscita del progetto è del 68% il progetto verrà comunque svolto, in quanto
tale sistema è ormai fondamentale e necessario all’interno della divisione, in particolare per i
Ricercatori. Inoltre non si è considerata la possibilità di esternalizzare il lavoro o acquistare un
15


pacchetto software già sul mercato in quanto il team voleva un’applicativo software costutio su
misura a seconda delle proprie esigenze e aspettative.

16


Appendice

Fig. 1- Stakeholders

Fig. 2- Modello a Spirale

17


Fig. 3- Work Breakdown Structure: Primo Livello di Scomposizione Progetto

Fig. 4- Work Breakdown Structure: Secondo Livello di Scomposizione

Fig. 5- Work Breakdown Structure: Scomposizione Analisi Preliminare

18


Fig. 6- Work Breakdown Structure: Scomposizione I Ciclo

Fig. 7- Work Breakdown Structure: Scomposizione II Ciclo

Fig. 8- Work Breakdown Structure: Scomposizione III Ciclo

19


Tab. 1-Work Breakdown Structure Table

20


Tab. 2- Costi del Personale espressi in ore/uomo

21


Tab. 3- Costing su Work Breakdown Structure

22


23


24


Fig. 9- Diagramma di GANTT ( presentato diviso per cicli di vita per leggibilità)

25


Tab. 4- Attività (Tempi espressi in giorni) - “Valutazione Temporale task e sequencing”

Fig. 10- Grafo AON

26


Tab.5 - Program Evaluation and Review Technique ( PERT )

a + 4m + b
Te = E(β) = → Tempo atteso di una attività
6

b−a
2

Var(β) = σ = 2
 → Varianza di una attività
 6 

Determinazione del sentiero, unico e critico:

ABCDEFGHIJKLMNOPQ = ∑ E (attività) = Va(A)+ Va (B)+ Va (C)+ Va (D)+ Va (E)+
Va (F)+ Va (G)+ Va (H)+ Va (I)+ Va (J)+ Va (K)+ Va (L)+ Va (M)+ Va (N)+ Va
(O)+ Va (P)+ Va (Q)= 160,92 SENTIERO CRITICO

27


La varianza attesa del critical path è la seguente:

Var(CP) = σ 2 (CP) = ∑Var (attività) = var(A) + var(B) + var(C) + var(D) + var(E) + var(F) +

var(G) + var(H) + var(I) + var(J) + var(K) + var(L) + var(M) + var(N) + var(N
O) + var(P) + var(Q) = 20,76

Quindi il sentiero critico sarà completato con un valore atteso di 160,92 giorni e con una varianza di
± 20,76 giorni.

Deviazione standard del sentiero critico: S = σ 2 (CP) = 20,76 = 4,56

Voglio vedere la probabilità di terminare il progetto prima del tempo Td = 170 giorni

Td − Te 170 − 160,92
z(t) = = = 1,991
S 4,56
Quindi la probabilità di terminare il progetto si trova dalla tabella della distribuzione normale:

 T − Te 
Pr (T ≤ Td) = Pr  z ≤ d  = 0,9767 ⇒ 97,67% di probabilità di terminare in meno di 180
 S 
giorni.

La probabilità di terminare in meno di 163 giorni è invece:
Td − Te 163 − 160,92
z(t) = = = 0,4561
S 4,56

 T − Te 
Ciò significa: Pr (T ≤ Td) = Pr  z ≤ d  = 0,6772 ⇒ 67,72% di probabilità di terminare in
 S 
meno di 163 giorni.

28

Project Management

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Project Management

Similar a Project Management (20)

Project Management