Quando si apre una nuova posizione in azienda, la prima regola non scritta è individuare il vero decisore. Non necessariamente il capo formale, né chi ha il titolo più alto, ma chi effettivamente prende le decisioni che contano, spesso alla “macchinetta del caffè”. Individuare il decisore è una competenza che si affina con l’esperienza e può risolvere molti problemi prima che esplodano.
Lo stesso principio vale quando si fa il kick-off di un progetto IT. Prima di iniziare qualsiasi attività, i project manager esperti sanno di dover identificare e assicurarsi il sostegno di due figure cruciali: lo sponsor finanziario, che tiene i cordoni della borsa, e lo sponsor politico, colui che apre porte e rimuove ostacoli.
Indice degli argomenti
Il grande assente: il Service Owner
Eppure, c’è uno stakeholder che sistematicamente manca al tavolo del progetto dall’inizio: il Service Owner, la figura responsabile della gestione complessiva di un servizio IT lungo tutto il suo ciclo di vita. Il gestore del servizio non deve essere interpellato alla fine, quando è troppo tardi e i riflettori del go-live si sono spenti. Per occuparsi efficacemente del day-by-day deve entrare nel piano decisionale dall’inizio, quando vengono gettate le fondamenta.
Questa figura, invece, viene spesso coinvolta nelle ultime settimane, prima dell’ultimo rilascio, a progetto quasi completato. È come invitare qualcuno a cena, e quando i piatti sono già in tavola, chiedere ai commensali se gradiscono gli ingredienti.
Due ruoli, due mondi
Il problema nasce da una confusione di ruoli. Il Project Manager e il Service Owner hanno obiettivi e orizzonti quasi opposti, sia in termini temporali che esecutivi.
Il Project Manager vive nel mondo finito dei progetti: ha una data di inizio e una di fine, un budget da rispettare e milestone da raggiungere. Il suo successo si misura sulla capacità di consegnare quanto promesso, nei tempi e con le risorse allocate. È una corsa contro il tempo dove l’efficienza è tutto.
Il Service Owner, invece, abita il mondo continuativo dei servizi. Per lui, il go-live non è un traguardo ma un punto di partenza. Si preoccupa della continuità operativa, della fruibilità, della manutenibilità e dell’evoluzione del servizio. Il suo incubo non è il ritardo di una settimana, ma un sistema che, tra sei mesi, si riveli ingestibile e generi continue chiamate all’help desk.
Il costo del ritardo
Quando il Service Owner entra in gioco troppo tardi, le conseguenze sono inevitabili. Un’interfaccia utente funzionale in demo si rivela ostica nell’uso quotidiano. Una procedura di backup perfetta sulla carta richiede interventi manuali non previsti.
Il risultato? Costi nascosti che emergono nella fase di esercizio, escalation continue verso i manager e fornitori, utenti frustrati che aggirano il sistema ufficiale chiamando l’IT amico… e un Service Owner costretto a giocare costantemente in difesa.
L’effetto finale è una bassa qualità del servizio, un debito tecnico che non si riesce a sanare e un nulla di fatto sul miglioramento continuo.
Anticipare è la parola d’ordine
La soluzione è semplice da enunciare, anche se richiede un cambio di approccio da parte della gerarchia e del Project Management Office (PMO): il Service Owner deve sedere al tavolo fin dal kick-off del progetto. Non come osservatore, ma come stakeholder e influenzare a pieno titolo.
Deve avere voce in capitolo sui requisiti non funzionali, quelli che determinano la gestibilità del sistema: monitoraggio, logging, procedure di recovery, interfacce di amministrazione, documentazione operativa. Deve validare i processi di gestione degli incidenti prima che siano codificati. Deve assicurarsi che le metriche di successo includano anche indicatori di gestibilità.
Una partnership necessaria per creare valore
In un mercato dove la velocità è cruciale ma la stabilità è imprescindibile, la collaborazione tra Project Manager e Service Owner è una necessità. Il primo porta la disciplina del delivery, il secondo la visione del ciclo di vita completo e l’esperienza di produzione.
Quando questi due mondi si incontrano dall’inizio, i progetti IT non solo rispettano tempi e budget, ma generano servizi che funzionano, creano valore nel tempo e non diventano passività tecniche.
La prossima volta che parte un progetto, quindi, dopo aver trovato uno sponsor, cerchiamo il Service Owner. E diamogli una sedia al tavolo in pelle, non uno sgabello. Il successo del servizio (e quindi il lustro del progetto) dipende anche da lui.
