Efficienza del processo di sviluppo e raggiungimento degli obiettivi iniziali devono rappresentare i cardini per valutare i risultati in ogni step di un progetto
Dopo aver esaminato alcuni casi di scelta tra gestione interna e outsourcing (si veda Lineaedp nº 3 dello scorso 4 febbraio), il secondo appuntamento con il project management fa perno su esperienze aziendali reali per approfondire il tema della gestione delle diverse fasi di vita di un progetto, valutando i risultati sia in termini di efficienza del processo di sviluppo che di raggiungimento degli obiettivi iniziali (efficacia).
Gli errori del passato
Verso la metà degli anni 90, era comune che un progetto It corrispondesse a un sistema (anche se non sempre era vero il contrario), come se fosse possibile isolare la realizzazione di un particolare set di funzionalità dal resto dei sistemi informativi. Gradualmente, si è affermato il paradigma secondo cui l’It è fondamentalmente un fornitore di servizi, per cui in realtà è esso stesso il progetto.
Questo cambiamento ha comportato di dover passare da un approccio tutto sommato ancora “pionieristico”, in cui i progetti erano divisi secondo linee verticali, a un’impostazione in cui la suddivisione avviene perlopiù per aree/processi, all’interno dei quali emergono varie fasi: analisi, sviluppo, test e così via.
Circa dieci anni fa, ad esempio, fu lanciato un ampio programma di ridisegno complessivo dei sistemi informativi in un’importante azienda italiana, che abbracciava praticamente tutti i processi, sia di front che di back end. Dopo una prima fase di analisi “strategica”, che aveva l’obiettivo di impostare il master plan dei diversi sottoprogetti, uno per ogni processo, partì la fase di implementazione. Quest’ultima si è caratterizzata ex post per una notevole diversità rispetto all’esito previsto e agli obiettivi iniziali. Inoltre, alcuni progetti non hanno mai raggiunto il traguardo. La ragione principale di questa discrepanza potrebbe essere cercata nel fatto che i singoli progetti, pur rispondendo a un unico disegno di alto livello, non avevano avuto un coordinamento unitario. Inoltre, si era preferito creare tanti team di lavoro quanti erano i progetti, sicché non c’era alcuna trasversalità tra le diverse fasi del processo di sviluppo e quindi nessuna sinergia. Infine, i confini tra le diverse aree non erano sempre ben chiari. Più di una volta è stato necessario ridefinire i piani dei singoli sottoprogetti perché alcune funzionalità appartenevano a diversi di questi. Una situazione che, a sua volta, rendeva più difficile valutare ex post l’efficienza del progetto, dato che parte dell’effort era stato speso su attività di risoluzione di conflitti o di chiarimento delle opportunità.
In tempi più recenti, la riorganizzazione della funzione It seguita alla fusione tra due importanti aziende impegnate nel campo delle telecomunicazioni ha rappresentato un momento di trasformazione in termini di cultura, processi, organizzazione e tecnologie impiegate. Il background delle due aziende coinvolte non poteva essere più diverso. Una proveniva, infatti, da una start up di successo il cui approccio era stato sempre quello di reagire tempestivamente agli stimoli del mercato (anche se questo significava dare priorità alla rapidità di esecuzione piuttosto che al rispetto dei processi e delle procedure). La seconda, invece, godeva di una solida base clienti ed era caratterizzata da un approccio più “burocratico” nei rapporti It/funzioni utenti.
Subito dopo la fusione “civilistica”, le due sponde cominciarono a conoscersi e a misurare anche la propria distanza. In una riunione che ebbe luogo tra marketing e It per comprendere i requisiti che dovevano essere implementati su diverse piattaforme, gestite ancora dalle due organizzazioni, i referenti della ex start up si concentrarono sui tempi richiesti dal mercato in relazione ai nuovi requisiti e fecero domande per capire se un dato requisito potesse essere vincolante oppure no, oppure se ci fosse un modo per implementarlo in maniera light per ridurre gli impatti sui sistemi (che non si erano mai parlati fino a quel momento e per i quali era necessario realizzare delle nuove interfacce). La sorpresa fu grande quando i referenti It dell’altra parte risposero che alcuni requisiti non erano realizzabili. Si trattava, infatti, di rompere un tabù mai messo in questione nella società controparte: dichiarare che l’It era un ostacolo al raggiungimento degli obiettivi dell’azienda. A valle dell’incontro fu chiaro che non si trattava di un caso isolato, ma che la cultura dell’azienda di provenienza “ammetteva” situazioni di quel tipo.
Al momento della fusione “operativa” si pose poi il problema di come integrare non solo le strutture It delle due organizzazioni, ma anche le diverse tecnologie e i rispettivi sistemi informativi. Fu quindi varato un programma che si proponeva di far emergere nelle diverse aree i sistemi “duplicati”, quelli da dismettere perché non più adatti al nuovo contesto e quelli da adeguare per essere adattati alla nuova struttura. Questo processo è stato di non breve durata, generando, come è intuibile, resistenze e attriti tra le diverse aree e tra i gruppi provenienti dall’una e dall’altra azienda, ma alla fine ha dato luogo a un modo di lavorare pragmatico, basato sulla definizione formale di fasi necessarie in ogni iniziativa (studio di fattibilità, analisi funzionale, sviluppo, test e rilascio in produzione), su quella di rilasci cadenzati, cioè uguali per tutte le aree impattate a intervalli più o meno regolari, e su quella congiunta tra le diverse aree It e i diversi utenti dei contenuti di ogni singola release, in modo da trovare soluzioni condivise e chiarire eventuali dubbi sui requisiti prima dell’inizio delle attività di analisi.
Tale approccio ha permesso di gestire l’It a livello aziendale e non di singola iniziativa, il che, tuttavia, non significa che non siano stati commessi degli errori. In particolare, il processo di integrazione sarebbe stato più rapido se fosse stata creata una task force con l’incarico di studiare, in funzione dei costi e dei benefici passati e attesi su quali sistemi continuare a investire, quali dismettere in quanto duplicati, in base a tipologia ed estensione delle funzionalità coperte, quali spegnere perché non più utili alla nuova realtà aziendale, quali realizzare.
In alcuni contesti, inoltre, è stata creata un’unica struttura di analisi (demand) e una di sviluppo e test (solution), suddivise al loro interno per competenze o tecnologie, così da garantire la risoluzione tempestiva dei problemi e il rispetto dei tempi imposti dal mercato, grazie anche a una struttura di project manager il cui compito è quello di fare da tramite tra It e unità organizzative utenti.
In questo modo, è possibile ottenere, oltre a un miglior controllo in sede di realizzazione, anche maggiori benefici tra quelli attesi per una più alta sinergia tra le diverse aree impattate, una più adeguata stima iniziale degli effort (grazie alla fase di pre-analisi e tracciamento dell’intero processo), che permette di valutare l’efficacia dell’intera azienda e non delle singole aree rispetto al business case iniziale.
Il prossimo “stadio evolutivo” dovrebbe essere rappresentato dalla creazione di un unico pool di risorse che realizzano di volta in volta i requisiti definiti dal mercato sui diversi processi, modificando o configurando opportunamente sistemi informativi resi interoperabili e “simili” dall’adozione di Web service o altre tecnologie realmente out of box. Non si può dire quanto tempo occorrerà ma mi sembra che questa costituisca la vera sfida per l’It dei prossimi anni, se non decenni.
