Gestire un progetto IT

Barbara CascinoSenior Consultant & Resp. Sistemi Informativi at Cegos Italia



Qualche giorno fa, mi hanno chiesto di scrivere un articolo sulla gestione dei progetti IT.

La prima cosa a cui ho pensato è stata: "Non ho tempo".

La seconda: "Uso Copilot e lo faccio scrivere a lui" (o a lei...è questione di gender”).

E così ho fatto, ma è venuto fuori qualcosa di freddo ed asettico che non lasciava trapelare gli sforzi per mettere d'accordo tutti gli Stakeholder, la fatica nel rispettare i tempi di go-live a fronte di continui change-request, le arrabbiature nel vedere le riunioni di avanzamento disertate per altri impegni più urgenti o importanti...rendersi conto, a distanza di mesi, che il progetto non è stato il successo previsto.

A questo punto ho iniziato a pensare alle peculiarità e alle criticità da gestire. Alcune comuni a tutte le tipologie di progetto, altre più verticali sul mondo ICT.

Stakeholder

Uno stakeholder, per definizione, è qualsiasi persona interna od esterna che, direttamente o indirettamente, abbia a che fare col progetto.

Lo stakholder principale è lo Sponsor. Senza di esso, iniziare un progetto sarebbe altamente rischioso. Deve essere uno Sponsor di peso, sia come ruolo che come capacità di spesa, capace di aiutarti a raggiungere gli obiettivi del progetto.

Scelta del sistema/ piattaforma/ applicativo

Un progetto IT prevede, nella maggior parte dei casi, un cambio di infrastruttura o di applicativo. Il tutto può essere più o meno gravoso in termini di:

- Budget e controllodell'avanzamento dei costi. L'analisi dei costi, su un arco temporale di almeno 3 anni dal go-live, deve considerare quelli cessanti (che non sosterremo più grazie al nuovo sistema), quelli emergenti (che dipendono dalla nuova soluzione) e quelli indifferenti (che non vengono influenzati dal nuovo progetto). Non c'è nulla di peggio che vedere il budget ICT esplodere per non aver considerato dei costi futuri ricorrenti.

- Necessità di skill tecniche: con l'inserimento di nuove soluzioni, rischiamo di essere governati, e non governanti, dai nostri consulenti.

- Attenta e corretta valutazione delle nuove funzionalità del sistema. È - sicuramente un mio 'bias', ma i commerciali cercano sempre di portare acqua al loro mulino, promettendo funzionalità inesistenti o di difficile utilizzo per gli utenti finali. Non vanno create false aspettative.

- Impatto nel breve e medio periodo dei nuovi sistemi sulla popolazione aziendale.

Scelta del system integrator

Spesso in aula mi domandano: “È meglio un partner forte del suo nome, che può mettere a disposizione un pool importante di consulenti specializzati o è meglio un piccolo system integrator che è interessato a seguirti, in quanto non sei uno dei tanti clienti che deve gestire?

L'esperienza diretta mi insegna che tutto dipende dai consulenti allocati e dall'organizzazioneinterna del partner. Nessuno vuole un consulente che faccia esperienza sulle nostre spalle. Quindi la mia risposta è: “Cerchiamo di conoscere il PM e il team del system integrator prima di affidargli l'incarico. Assicuriamoci che in caso sostituzione dei componenti del team, il partner ci garantisca un approfondito e documentato passaggio di consegne”.

Approccio nella gestione del progetto

Waterfall o Agile? È questo il dilemma. Entrambi hanno punti di forza e di debolezza. Quindi un approccio ibrido potrebbe risultare la carta vincente:

- Avere una visione di lungo periodo per capire dove si vuole arrivare

- Focalizzarsi su risultati di breve periodo (chiamiamoli sprint o milestone a seconda dell'approccio)

- Coinvolgere costantemente l'utente finale (sia per motivarlo sia per attuare subito e velocemente azioni correttive). Quest'ultimo punto è stato per anni una mancanza dei progetti ICT.

Analisi dei rischi

Va fatta e va fatta con attenzione. Non deve essere un puro esercizio di stile. Il detto “Prevenire è meglio che curare” ne spiega chiaramente il motivo.

RBS, Ishikawa o SWOT analysis sono solo alcuni degli strumenti che ci possono aiutare. Usiamoli con un approccio “Zero base”. Non prendiamo quella di progetti precedenti, che ci può fornire degli spunti, ma che potrebbero non essere più applicabile a fronte di un nuovo contesto di business o di nuovi scenari economici.

Change Management

Un importante progetto IT, che prevede cambi a livello applicativo, deve essere accompagnato da un progetto di Change Management.

Il rispetto del paradigma “Lo so fare / Lo vedo fare/Lo voglio fare/ 'Sono messo in grado di farlo” diventa fondamentale per il suo successo.

Formiamo, quindi, l'utente all'uso del nuovo sistema, facciamogli vedere che altri lo utilizzano con successo ottenendo maggiore efficienza od efficacia, facciamogli comprendere che otterrà dei vantaggi diretti e personali. Tutto ciò lo porterà ad abbandonare le vecchie soluzioni.

Project Manager

Ebbene sì, noi PM siamo tra gli elementi critici da considerare. Lavorare sotto stress diventa un'abitudine, soprattutto in vista di milestone, sprint e go-live. La capacità di rimanere lucidi e obiettivi è fondamentale nel nostro lavoro.

È inutile innamorarsi di un progetto se vediamo già che è destinato a fallire. Bisogna avere il coraggio di dire “Stop”. Per concludere, è sempre tanta la soddisfazione di vedere un progetto nascere, svilupparsi e trasformarsi in una leva efficace per il business... ma che fatica!

Scopri il corso Cegos dedicato alla gestione di un progetto IT!

Scritto da

Barbara Cascino

Diplomata come Ragioniere e Perito Commerciale, dopo una specializzazione in linguaggio di programmazione Cobol e Analisi dati e programmazione strutturata, nel 1984 entra nel gruppo Cegos Italia come junior trainer. Dopo un breve esperienza presso un’altra società in qualità di Responsabile Assistenza Clienti, rientra in Cegos dove si specializzata nella formazione su tematiche ICT. Oggi è Senior Consultant e Responsabile dei Sistemi Informativi
Scopri di più
newsletter image

Ricevi la nostra newsletter

Training, Management, Commercial, Professional Efficiency

Iscriviti