Information and Communication Technology

I problemi che riguardano i progetti sono relativi a :

• ritardi nel concludere un progetto
• eccessivi mutamenti in corso d’opera
• indisponibilità delle risorse umane nel momento in cui si è stabilito
• indisponibilità delle infrastrutture necessarie nei momenti stabiliti (server, licenze, installazioni, collegamenti, ecc)
• conflittualità tra le priorità dei progetti
• superamento delle spese stabilite
• eccessive rielaborazioni di parti del lavoro

I problemi elencati si tende a risolverli dilatando i tempi di realizzazione del progetto e pregiudicando la qualità del lavoro.

In tutti e due i casi si presuppone in modo sbagliato che non si abbiano margini per gli imprevisti avuti.
In realtà il tempo a disposizione viene spesso sprecato. i progetti che terminano in ritardo sono molto al di sopra del 20 %.

Self Fulfillment

Il fenomeno appena descritto viene nominato fulfillment, le sue cause sono:

• perfezionismo
• sindrome dello studente
• mancanza di stimoli a portare a termine un progetto nei tempi stabiliti, anche a causa della mancanza di premi
• mancanza di focalizzazione
• presenza di milestone
• multitasking
• mancanza di reporting per gli anticipi e solo per i ritardi
• legge di parkinson

Gli effetti del fulfillment:

• potenzialità di terminare un progetto in anticipo non sfruttata adeguatamente
• progetti penalizzati da attività lavorative che terminano in ritardo
• perdita degli anticipi a discapito dei ritardi che si accumulano

gli effetti porteranno ineluttabilmente in un ritardo del progetto, vi è quindi occorrenza di un sistema che possa permettere al project manager di focalizzarsi sul progetto evitando lo spreco del safety time

Nuovo sistema di programmazione e controllo

• diminuire i tempi di ogni attività annullando i safety time di ognuno
• definire la protezione sui tempi di realizzazione del progetto (project buffer) che deve essere uguale o più basso ai safety time che si è riusciti a recuperare
• proteggere il cammino critico dai ritardi sui cammini non critici (buffer time)
• controllare il progetto facendo attenzione sul cammino critico e sulle risorse critiche (colli di bottiglia)

La costruzione del team di progetto

• all’interno della “micro-organizzazione” di un progetto avviene la nascita di un gruppo di progetto
• la “micro-organizzazione” viene costruita grazie ad un team di progetto
• il project manager ha tra le fondamentali attività quella di costruire un team di progetto

Definizione di un gruppo

• insieme di persone interdipendenti tra loro
• peculiarità di vita autonoma e unità dei componenti come caratteristiche che lo differenziano da altre forme associative

Specificità di un gruppo

• consapevolezza di essere parte di un gruppo con un’ immagine ben delineata
• gli scopi del gruppo sono in comunione
• chi fa parte di un gruppo ha la percezione dei ruoli, di comportamenti attesi, e della struttura di cui fanno parte, inoltre sono capaci di collocare se stessi e gli altri in questo sistema
• chi fa parte del gruppo ha la consapevolezza dei valori, delle norme di comportamento, di un linguaggio e un di codice, e che essi sono riconosciuti dagli altri componenti del gruppo

Caratteristiche comuni ai gruppi di progetto

• coordinarsi verso le attività di un progetto
• responsabilizzarsi nei compiti degli appartenenti al gruppo
• suddividersi ruoli, funzioni, responsabilità, competenze e mansioni
• essere consapevoli di focalizzare energie e comportamenti per arrivare al successo dell’attività
• volontà nella collaborazione al progetto con sincerità verso gli atri del gruppo e approvazione della figura del project manager con la volontà di arrivare al successo del progetto
• avere la chiarezza dello scopo del progetto come base fondamentale di esso
• la produttività e un buon morale come base essenziale per raggiungerei risultati attesi
• strumenti per raggiungere tali scopi sono: l’autorità, le relazioni, la comunicazione, la flessibilità, il riconoscimento e l’apprezzamento

Differenze tra gruppi efficaci e non efficaci:

Le decisioni nei gruppi efficaci sono conseguenti alla situazione, vi è consenso e il gruppo ne è coinvolto. Nei gruppi non efficaci vengono prese solo agli alti livelli e non vi è coinvolgimento.

Le controversie nei gruppi efficaci sono risolte attraverso il coinvolgimento dei suoi membri mentre nei gruppi non efficaci essi sono trascurati.

I comportamenti nei gruppi efficaci sono agevolati, sia fra i vari gruppi che fra gli appartenenti ad essi, mentre nei gruppi non efficaci vengono accentuate le azioni individuali e non si da importanza al coinvolgimento fra i membri del gruppo.

I problemi del solving nei gruppi efficaci è alta mentre è bassa nei gruppi non efficaci.

La valutazione tra i membri dei gruppi efficaci è sia per l’efficacia del suo team di appartenenza che per la sua funzionalità, nei gruppi non efficaci la valutazione è un “privilegio” solo degli alti livelli.

L’ incoraggiamento nei gruppi efficaci è relativa alla realizzazione personale e verso il rinnovamento, nei gruppi non efficaci si incoraggia solo la stabilità e la rigidità della struttura.

Gli obiettivi nei gruppi efficaci servono alla cooperazione fra i membri e cambiano a seconda dei fini individuali e di gruppo, nei gruppi non efficaci le decisioni sono pensati in modo competitivo e sentiti come obbligo.

Le comunicazioni nei gruppi efficaci sono a due vie ed è manifestato il pensiero dei membri, nei gruppi non efficaci sono ad una via e il pensiero dei membri non è considerato.

La leadership nei gruppi efficaci è ripartita fra i suoi membri, nei gruppi non efficaci è solamente autoritaria.

La partecipazione nei gruppi efficaci è verso un coinvolgimento equo e globale, nei gruppi non efficaci è solo per gli alti livelli.

Il potere nei gruppi efficaci è equamente distribuito per la soddisfazione dei singoli individui, nei gruppi non efficaci il potere risiede solo agli alti livelli, gli altri membri devono solo obbedire.

Le funzioni del project manager sono:

• pianificazione del lavoro da attuare per arrivare agli obbiettivi delineati
• organizzazione del gruppo di lavoro che attuerà il progetto
• implementazione del lavoro assegnandolo al gruppo di lavoro
• controllo della fase in cui il lavoro sta procedendo
• mantenere i contatti con il cliente, sia interno che esterno
• guida del gruppo di lavoro

Le funzioni del team di lavoro prevede:

• motivazione e riconoscimento
• mantenimento della visione sul gruppo di lavoro
• incoraggiamento di ciò che il team di lavoro decide
• controllo e mantenimento del comportamento del team di lavoro
• risoluzione delle divergenze
• assicurazione del beneficio dei componenti del gruppo di lavoro

Caratteristiche basilari per svolgere il ruolo del project manager:

• concreto orientamento verso gli obiettivi
• completa cognizione del contesto in cui il gruppo di lavoro opera
• preparazione professionale generale
• valutazione e risoluzione dei problemi
• abilità nel gestire le risorse
• abilità nella gestione dei rapporti coi clienti
• leadership

Le principali attività da delineare alla base di ogni progetto:

• creazione immediata di una cultura di gruppo
• definizione chiara delle finalità del progetto
• definizione dell’organigramma del progetto
• organizzare con le organizzazioni di linea come il progetto verrà pianificato e come le risorse utilizzate
• definizione dei modelli in cui il lavoro sarà gestito e quali saranno le procedure e le routine amministrative
• definizione delle modalità di comunicazione efficaci

Alcune difficoltà:

• dislivello tra autorità e responsabilità. Alle responsabilità del project manager non viene riconosciuta la relativa autorità, essa può essere ottenuta solamente tramite l’affermaizone delle sue capacità.
• dislivello tra il fine del progetto e il fine dell’organizzazione. Un progetto può essere suddiviso in molteplici parti e i loro fini possono essere divergenti.
• dislivello tra il modello di direzione di un progetto e quello funzionale. La gestione dei progetti a volte necessita di mutamenti e le organizzazioni devono operarsi in questa evoluzione per seguirli

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.