Article by Sara Curzel

Progetti IT su larga scala – best practices (parte 2)

In questa seconda parte dell’intervista con Johan Vorster esaminiamo l’importanza per i progetti IT di avere strutture di governance adeguate, oltre ad alcune best practice per gestione di progetti IT su larga scala. Hai perso la prima parte? Leggila qui!

  • Come stabilire strutture di governance che si occupino dell’interesse dei vari stakeholder?

Ho visto fallire progetti molto buoni solo perché non avevano strutture di governance. Quando consegni un progetto ad un cliente, sia il fornitore che il cliente dovrebbero possedere strutture di governance adeguate. Una buona struttura di governance offre al progetto benefit molto importanti quali: supervisione, obiettività, reattività, apertura, equità e responsabilità. E dovrebbe anche essere in grado di affrontare efficacemente i conflitti.

Sono stati scritti molti libri sulla governance. A me piace mantenere semplice la questione, la mia idea di una corretta governance è che ogni persona all’interno del progetto deve sapere esattamente cosa ci si aspetta da lui/lei (avere un mandato chiaro), ci dovrebbe essere una corretta supervisione di qualsiasi individuo e del gruppo e una chiara separazione del potere a tutti i livelli (vale a dire che nessuna persona dovrebbe avere l’autorità di prendere decisioni importanti autonomamente); deve poi esserci tracciabilità e una documentazione adeguata. In un ambiente di progetto, ci devono essere organi di controllo con un mandato per il monitoraggio dei progressi, l’approvazione dei cambiamenti (gestione delle modifiche) e la supervisione di tutte le attività.

All’inizio del progetto, uno dei primi risultati dovrebbe essere la finalizzazione della struttura di governance, un elemento d’azione da completare prima dell’avvio del progetto. La struttura di governance deve essere documentata e deve definire gli organi, come sono formati, e qual è il loro ruolo e mandato.

È necessario anche istituire un comitato direttivo centrale, quale autorità decisionale più elevata all’interno del progetto. Sia il fornitore che il cliente dovrebbero poi sedersi allo stesso tavolo del comitato direttivo per prendere decisioni vincolanti sul progetto. Il comitato direttivo ha il compito di monitorare i progressi e approvare le richieste di cambiamento. I mandati del project manager lato fornitore e del project manager lato cliente devono essere documentati. Il mandato e il ruolo dell’ufficio centrale del progetto deve essere registrato e si dovrebbero utilizzare modelli RACI per redigere tutti i principali processi, riportando il responsabile, chi dovrebbe essere consultato e chi dovrebbe essere informato ad ogni passo del processo.

È necessario stabilire un organismo che si occuperà della base di sviluppo del software e della priorità dei requisiti degli utenti, al quale parteciperanno sia responsabili lato fornitore che lato cliente con lo scopo di prioritizzare nuove funzionalità software e richiederne l’approvazione al comitato direttivo. Una volta documentata la struttura di governance, questa dev’essere approvata dal fornitore e dal cliente. Le posizioni sono definite nel documento e l’esecuzione del progetto viene poi effettuata alla luce di questo.

  • Come affrontare il fallimento di un progetto?

I progetti che hanno una struttura di governance formale e un comitato direttivo centrale hanno possibilità di fallimento molto inferiori ai progetti che non sono strutturare in questo modo. Presupponendo che un progetto abbia un comitato direttivo centrale, questo dovrebbe occuparsi dei possibili fallimenti. In generale, raramente un progetto fallisce bruscamente. Di norma le luci rosse iniziano a lampeggiare durante la lavorazione e il comitato di gestione del rischio dovrebbe avvisare pro-attivamente il comitato direttivo e richiedere l’intervento. In definitiva, il comitato direttivo dovrebbe assumersi la responsabilità per il successo di un progetto, ma anche per il suo eventuale fallimento. Nel caso in cui il progetto venga interrotto, il comitato direttivo dovrà decidere un piano di scioglimento e le parti interessate potrebbero anche formalizzare un ricorso.

  • Puoi condividere le migliori pratiche dalla tua esperienza nella gestione di progetti IT su larga scala?

Innanzitutto, il campo di applicazione del progetto dovrebbe essere chiaramente definito e documentato, con un processo di gestione delle modifiche dettagliato e concordato da tutti i soggetti interessati. La struttura di governance deve essere approvata da tutte le parti interessate, i ruoli e le responsabilità devono essere istituiti e dovrebbe essere creata una struttura decisionale in grado di evitare gli ostacoli che si potrebbero verificare. Un organo di amministrazione dovrebbe essere attuato dall’ufficio centrale di progetto. L’eventuale ripartizione del lavoro tra diversi fornitori o subappaltatori deve essere chiaramente definita e deve essere basata su una struttura logica di ripartizione del lavoro, per evitare ambiguità. Infine, il progetto deve avere un registro di rischio formale e un comitato di gestione del rischio che sieda regolarmente e si occupi in modo proattivo degli eventuali rischi del progetto.

Rispondi

L'unione fa la forza

I nostri rivenditori sono in grado di sfruttare al meglio la nostra tecnologia e lavorano con noi per disegnare le soluzioni ottimali per te.

Clienti

Hanno scelto di utilizzare le soluzioni Praim