Information and Communication Technology

I documenti che vengono prodotti all’interno di un progetto vengono definiti “deliverables di progetto”.
Tali documenti possono essere di quattro tipi:

• procedurali
• tecnici
• a supporto degli utenti
• operativi

DOCUMENTI PROCEDURALI

La guida di progetto accoglie le linee guida di gestione del progetto concordate tra le parti: schedulazione, risorse di progetto, modalità di rilevazione attività, modalità di controllo avanzamento, criteri di gestione delle revisioni e delle richieste di modifica, scelte di implementazione.

DOCUMENTI TECNICI

La definizione di un prodotto è data dai documenti che hanno valore contrattuale e fungono da punto di riferimento di tutto il progetto.

DOCUMENTAZIONE A SUPPORTO DEGLI UTENTI FINALI

La documentazione di supporto è costituita prevalentemente dai manuali d’uso e dalla documentazione rilasciata a seguito delle attività di formazione.

DOCUMENTAZIONE OPERATIVA

La documentazione operativa include tutti i documenti che nel corso dell’attività di progetto vengono predisposti per dare visibilità ai partecipanti dell’avanzamento del progetto. Tra i documenti che sono necessari si hanno: verbale di riunione, project plan, report avanzamento, elenco degli “open point”, registro delle decisioni.

Le fasi di qualsiasi progetto possono mutare a seconda della tipologia del progetto, dell’applicativo che si sta usando e del contesto in cui avviene la sua realizzazione

Le fasi principali di un progetto sono: l’analisi, il disegno, lo sviluppo, la pubblicazione e il supporto.

ANALISI

Nel corso di questa fase sono spiegati gli obiettivi di progetto, la pianificazione e l’organizzazione progettuale. In questa fase sarà necessario produrre dei documenti inerenti le necessità dei clienti che saranno successivamente vagliati e approvati da loro stessi (Functional Requirements Document FRD).

Le attività previste in questa fase saranno: la pianificazione del progetto, l’identificazione delle risorse e dei fabbisogni hardware e software, la pianificazione del training, l’identificazione e attivazione del software presso il cliente, la formazione del personale sulle funzionalità, la pianificazione delle attività successive.

DISEGNO

L’ Enterprise Design Document (EED) rappresenta la parte finale della fase di disegno che verrà implementato con illustrazioni al sistema.

La fase di EED prevede:

• compilazione del documento EDD.
• parametrizzazione prototipale dell’applicativo.
• delineazione dei system test plan a seconda dei business cases che sono stati riscontrati.
• individuazione delle personalizzazioni più importanti.
• individuazione delle interfacce.
• delineazione del metodo in cui i dati vengono convertiti.

SVILUPPO & TEST

La fase di sviluppo e test (development & testing) è il sistema interamente parametrizzato e testato.

Contemporaneamente alla fase di customizzazione del sistema ci sarà la realizzazione dei programmi di interfaccia con le relative personalizzazioni.

Le principali attività previste in questa fase sono: l’analisi tecnica, lo sviluppo e il test dei programmi di interfaccia e dei programmi di conversione, la verifica sulla formazione degli utenti, realizzazione ed accettazione dell’Integration Test da parte dei Key Users.

PUBBLICAZIONE

In questa fase avviene il vero e proprio rilascio del sistema di produzione, le cui attività sono:

• programmazione e attuazione delle attività, dopo aver definito quali siano i ruoli e le attività
• controllo dell’applicativo sul sistema di produzione e generazione dell’ambiente
• conversione dei dati definitiva
• training utenti finali
• rilascio finale dei documenti del sistema
• rilascio del sistema in produzione

SUPPORTO POST PARTENZA

• impostare un help desk
• training “on the job”
• ausilio di applicativi e di operativi

FATTORI CRITICI DI UN PROGETTO ICT

I fattori che possono creare problemi al successo di un progetto ICT sono:

• spese eccessive rispetto a quanto stabilito
• obiettivi non chiari
• incapacità decisionale
• tempi esigui nella realizzazione dei lavori
• eccessivo numero di interlocutori
• confusione nelle decisioni
• non omogeneità nell’attività dei membri del gruppo del lavoro
• strumentalizzazioni interne
• cambi eccessivi tra le leadership
• disciplina eccessivamente autoritaria
• bassa considerazione delle procedure

Nei progetti ICT i partecipanti al progetto possono assumere ruoli diversi.

• SPONSOR: rappresenta chi ha commissionato il progetto, può essere un individuo o un gruppo di persone.
• REFERENTI DI PROGETTO: sono le persone fiduciarie degli sponsor che hanno la responsabilità del progetto
• PROJECT MANAGER: solitamente è un ruolo che riveste la software house esterna all’azienda, se interno è il referente del progetto.
• COMITATO GUIDA: gruppo di persone individuato dall’azienda per risolvere problemi tecnici o organizzativi, nei momenti critici del progetto.
• UTENTI: beneficiari dell’applicativo. Tra essi un ruolo più specifico è dato dai key users rappresentati dagli utenti con più competenza.
• KEY USERS: persone il cui fine è illustrare le specificità dei processi e capire quali siano le funzioni dell’applicativo.
• DECISORI: persone che hanno la responsabilità di decidere su aspetti organizzativi interni.
• OPINION LEADER: non essendo in grado di prendere decisioni il loro unico ruolo è di esprimere opinioni.
• MANAGER: membri del gruppo di progetto che concentrano in essi caratteristiche decisionali, organizzative e di visione d’insieme.
• PROFESSIONAL: persone la cui caratteristica è un’elevata competenza tecnica, ma mancano di visone d’insieme.
• SABOTATORI: persone che vedono nel fallimento del progetto il loro fine.

IL PARTECIPANTE PERFETTO AI PROGETTI ICT

Il ritratto del partecipante perfetto ai progetti ICT può essere riassunto in questo modo:

• esperto nel suo settore di lavoro
• pratico e concreto
• abilità nella visione d’insieme del progetto
• carattere efficiente e costruttivo nello svolgimento del lavoro
• cosciente delle caratteristiche positive e negative del progetto
• volenteroso nella cooperazione con gli altri membri
• onesto riguardo la valutazione e la comunicazione della discutibilità dei progetti
• leadership sia per la cooperazione che la motivazione dei membri dei gruppi
• disponibilità verso un aggravio di energie per raggiungere il successo dei progetti

CONSIDERAZIONI GENERALI DEI MODELLI ORGANIZZATIVI

Il modello organizzativo deve tener conto sia dei membri che fanno parte dell’azienda che dei membri esterni, anche se il progetto di lavoro è sviluppato solo tramite membri interni non mutano le caratteristiche che devono esserci.
Il modello funzionale si usa soprattutto nei progetti che hanno un alta standardizzazione oppure dove la presenza del contributo degli utenti è poco considerevole.
La difficoltà del progetto in relazione delle risorse umane e alle attività deve essere adottata sia alla matrice funzionale che alla matrice bilanciata.
L’organizzazione dei membri interni di chi si occupa del progetto e i membri che svolgono lavori esterni ad devono relazionarsi al modello matrice di progetto e il modello matrice multifunzionale.
Nei progetti con dimensioni medie o grandi si deve usare il modello core team o il modello team autonomo. Tra i due quello migliore risulta il core team nel caso di progetti di grandi dimensioni per il suo controllo sulle risorse e il collegamento tra le attività.

MODELLI ORGANIZZATIVI DEI PROGETTI ICT

1. PROGETTI PICCOLI

Il project manager può essere rivestito anche da chi ha un ruolo tecnico. il suo obiettivo è verificare lo sviluppo del progetto relazionandosi con chi ha sponsorizzato il lavoro. Il gruppo tecnico che si occupa del lavoro deve creare interesse ai referenti aziendali se le esigenze lo richiedono. Non si tratta di una vera e propria struttura organizzativa ma più precisamente di un unico gruppo di lavoro.

2. PROGETTI STANDARD

Il project manager può essere un tecnico o un coordinatore a seconda della grandezza del progetto. Se il progetto ha un contenuto tecnico il gruppo aziendale sarà scarsamente coinvolto. Solitamente il committente interno non prenderà parte al progetto.

3. PROGETTI DIPARTIMENTALI

Il Project manager deve essere un coordinatore rappresentando i fini del committente. Le risorse dell’impresa svolgono il loro impegno nella descrizione delle singole attività e in un secondo momento nell’avvio dell’applicativo. Le attività e i tempi di relizzazione di un progetto devono essere tenute in considerazione dalle risorse tecniche.

4. PROGETTI ERP

Il project manager non può essere un tecnico o un coordinatore a causa della grandezza del progetto, tale ruolo sarà svolto dal project office.
Il project office si occuperà di redarre i verbali, dei report di sviluppo del lavoro, di aggiornare i Gantt di progetto, di verifiche su tempi e costi.
Per relazionarsi con lo steering committee e con i project leader, il manager deve avere una buona visione d’insieme. I project leader nel lavoro che gli è stato assegnato sono dei piccoli project manager e sono divisi per processo o competenza tecnica. All’interno di ogni impresa dovrebbe essere presente un referente (team leader) per le relazioni con il project manager.

Il fine della la coordinazione tra il project manager e il team leader è quello di coordinare le risorse operative. il mantenimento dei canali comunicativi cosi come sono stati pensati ha lo scopo di non creare confusione nelle specifiche e nelle decisioni.
I project manager hanno la possibilità di relazionarsi tra di loro per gli aspetti tecnici in cui sono coinvolti e nel far questo possono interpellare anche i team leader.
la caratteristica essenziale del project manager è quella di avere sempre consapevolezza sullo stato del progetto.

ULTERIORI ASPETTI ORGANIZZATIVI

Dimensioni del progetto

Con l’aumentare della grandezza del progetto aumentano le criticità in quanto crescono le connessioni e le decisioni
per superare questo problema è fondamentale essere categorici sul ripeto delle procedure e delle decisioni intraprese

Verifica con lo sponsor

I tempi e i risultati che si sono acquisiti vanno sempre comunicati agli sponsor in quanto è necessario aggiornare lo sviluppo dei lavori e dare conferma degli obiettivi

Approccio top-down o bottom-top

Nei progetti di grandi dimensioni si deve dare la preferenza all’approccio top-down. l’approccio bottom-up può essere usato successivamente per sistemare quanto si è già deciso

Problemi con gli sponsor

Possono sussistere problemi con gli sponsor nel momento in cui non sa bene quali siano i suoi obiettivi e se il progetto ha grandi dimensioni delegherà ad altri la decisione sugli obiettivi

Per una migliore organizzazione è fondamentale scegliere il metodo di lavoro, la struttura organizzativa e gli interlocutori, analizzare le fasi di progetto, presentare il progetto al gruppo dei decisori, annotare le decisioni prese e pianificare tutte le attività.

L’immagine degli applicativi informatici utili ai progetti ICT è stata un po’ distorta da parte dei mezzi di comunicazione.
Da un lato è vista come “esoterica, dall’altra come la possibilità di eseguire qualsiasi azione a piacimento.
Questa immagine archetipa fa nascere i miti dell’hi tech: l’applicativo informatico e dotato di pensiero ed intelligenza, lavora per me e produce da solo.
Questi concetti inesatti fanno nascere disillusione da chi usa gli applicativi informatici. Si deve prendere atto che in realtà gli applicativi elaborano i dati che hanno ricevuto e l’elaborazione è data in base alle funzioni che abbiamo immesso. Siamo noi a guidarli.
L’unica possibilità che si ha nel far coesistere il mito con la “realtà” del progetto è quindi nel mettersi nei panni di chi usa il prodotto e di chi lo commissiona.

I progetti ICT (Information Communication Tecnology) generano sempre processi; un applicativo ICT deve essere funzionale al processo per il quale è stato progettato. Un progetto ICT finisce solo quando i processi sono stati avviati.

Le classi di progetto si differenziano in base a due fattori: unicità (livello di customizzazione) e complessità (numero di persone coinvolte.

SUDDIVISIONE RISPETTO ALLA CLASSE DI UNICITA’

• PACCHETTO STANDARD: l’applicazione non è modificabile e deve essere configurata e usata secondo quanto le necessità prevedono.
• PACCHETTO STANDARD CON PERSONALIZZAZIONE: si parte da un applicativo con funzioni già stabilite, ma che permettono una futura personalizzazione.
• PACCHETTO CUSTOM: viene costruito un progetto da una base iniziale tenendo conto delle necessità del mandatario.

SUDDIVISIONE RISPETTO ALLA CLASSE DI COMPLESSITA’

• PROGETTO PICCOLO (persone coinvolte inferiore a 5): piccolo team, rapporto diretto tra il mandatario e chi svolge.

• PROGETTO MEDIO (coinvolte da 5 a 10 persone) caratterizzato dalla presenza di un project manager intorno al quale si aggrega il team di sviluppo e gli utilizzatori.

• PROGETTO GRANDE (coinvolte più di 20 persone): il controllo delle aree di sviluppo non è affidato ad un project manager ma suddiviso tra team leader specifici; viene coinvolto nel progetto un gruppo di key users (utenti selezionati) piuttosto che la committenza.

• PROGETTO GRANDISSIMO: il progetto viene suddiviso in parti che sono legate a singoli project manager a causa dell’alto numero di persone coinvolte, della grandezza dei problemi e delle competenze che devono essere gestite.

Si individuano 4 classi di progetti

1) progetti “piccoli” – caratteristiche:

• stretta connessione tra chi decide e chi agisce
• feedback istantaneo sull’eventuale successo del progetto
• necessario legame tra le parti del progetto che aiuta anche nella mediazione
• bassi problemi di gestione per il suo facile controllo

2) progetti “standard” – caratteristiche:

• complessità non data dall’applicazione ma dall’estensione
• essenzialità delle specifiche iniziali come base del progetto
• gestione “ingegneristica” del progetto
• importanza dei tempi e della ripartizione del lavoro

3) progetti “dipartimentali” – caratteristiche:

• netta separazione tra il commettente e il personale
• mediazione tra i fini del committente e i fini e le interpretazioni del team di lavoro
• necessità di dirigere i tempi e il sincronismo tra i tecnici
• necessità di relazionarsi con tecnici di altre case

4) progetti “erp o grandi” – caratteristiche:

• necessità di disciplina e metodo per evitare di far confusione nel progetto
• possibile presenza di “nemici” all’interno dei partecipanti al progetto
• stretta relazione tra la perdita di tempo e i costi del progetto
• possibile incontrollabilità del progetto
• essenzialità di buone relazioni agli “alti livelli”
• necessità di chiarire le potenzialità e le funzionalità del progetto per il suo migliore utilizzo
• problematicità della leadership della committenza per il raggiungimento dei fini del progetto
• essenzialità del project manager per il coordinamento
• essenzialità del capo progetto per la supervisione dei lavori
• suddivisone degli aspetti tecnici in determinate aree di competenza

La Cost Breakdown Structure (CBS) raffigura l’articolazione delle spese per classe di costo.
La Coniugazione di Work Breakdown Sructure e Cost Breakdown Structure raffigura come i costi di progetto verranno distribuiti.
I costi per centri di responsabilita’ sono riuniti attraverso il rapporto OBS/CBS.

Il CBS è un progetto presentato attraverso un grafico che aiuta nella pianificazione e nella sua verifica. Tale rappresentazione è quindi alla base di ogni decisione di management

Gli obiettivi della CBS sono quelli di specificare le attività critiche, per evitare così dei ritardi nel progetto, conoscere la situazione del progetto per verificare quale sarà la data prevista per il suo completamento.

La Milestone rappresenta un punto intermedio ed è un dato fondamentale necessario ad ogni progetto in quanto è la misura di quanto si è raggiunto.

Le tecniche previste sono GANTT sequenze temporali e PERT-CPM sequenze temporali e interdipendenze.

Il Program Evaluation and Review Technique (PERT) è lo strumento per pianificare, progettare e controllare le attività che formano un progetto.

I fini del Program Evaluation and Rewiew Technique possono essere elencati in fasi:

• la presentazione delle varie attività che portano alla realizzazione di un progetto e quanto esse possono influenzarsi tra di loro
• la definizione dei tempi di realizzo e le fasi critiche che si potranno avere
• l’ottimizzazione e la realizzazione di un progetto
• il controllo delle fasi di lavoro nella realizzazione di un progetto

Per la costruzione di un progetto è fondamentale elencare le attività e capirne la durata, decidere la sequenza, costruire la struttura, calcolare i tempi previsti per la realizzazione ed eventuali problemi che si possono creare durante il percorso.

La WBS, acronimo di Work Breakdown Structure, descrive le attività che bisogna sviluppare per finalizzare un progetto, attraverso vari livelli di realizzazione che terminano nel Work Package (livello operativo che controlla quello che si è realizzato). La WBS è l’elemento base per la strutturazione del progetto, sono quindi collegati i concetti di “ottimizzazione” e “standardizzazione”.

I criteri di formulazione della WBS sono: logica funzionale e sistemi, fasi temporali e attività, logica dei processi di lavoro, logica spaziale, misto.

L’ Organizational Breakdown Structure (OBS) è la struttura organizzativa per gestire e realizzare un progetto.

La confluenza tra ” Work Breakdown Structure ” e “Organizational Breakdown Structure” individua le risorse stabilite al team di progetto.
E’ il modo più efficace per creare un nesso tra le persone e le loro relative attività e di conseguenza responsabilizzarle verso il loro lavoro.

La WPD (Work Package Definition) descrive una o più attività per la quale è necessario un numero limitato di ore e risorse che viene definito in sede di pianificazione della precedente WBS.

Gli obiettivi della WPD permettono la progettazione e il controllo del progetto a livello operativo e consentono di assegnare le responsabilità.

La WPD ha caratteristiche principali importanti:

• permettono di avere un contenuto provabile e concreto, e rendono possibile definire la quantità che di conseguenza è misurabile
• ha dei contenuti obiettivi e quidi è possibile il suo “controllo”
• nell’ambito dell’organizzazione l’attuazione è riconducibile ad un solo elemento il quale ha la responsabilità della realizzazione
• rispetto ad altri WP le interfacce di input e output sono evidentemente definibili
• i tempi di lavoro sono ben definiti e di conseguenza anche i relativi budget di spesa
• non è possibile una sua successiva suddivisione con obiettivi di verifica e programmazione
  

Il project manager ha lo scopo di raggiungere un risultato unitario attraverso l’utilizzo di attività organizzate e collegate e l’uso di risorse diverse. L’attenzione è rivolta ai fini prefissati assolvendo vincoli di tempo, spese e risorse.

1. LA RELAZIONE TRA PROCESSO E PROGETTO INTERNO

2. CLASSI DI PROGETTO

3. MODELLI ORGANIZZATIVI

4. LA PIANIFICAZIONE DEL PROGETTO

5. GLI STRUMENTI DELLA PIANIFICAZIONE

- STRUTTURALI (WBS – Work Breakdown Structure)

- ORGANIZZATIVI (OBS – Organizational Breakdown Structure)

- PIANIFICAZIONE COSTI (CBS – Cost Breakdown Structure)

- TEMPORALI (GANTT, PERT, CPM)