Cercando di aumentare il valore per gli stakeholder aziendali, Equinix sta adottando un modello di gestione basato sul prodotto per creazione soluzioni. Ma l’evoluzione dalle pratiche tradizionali di project management è complessa e comporta insidie che possono inficiare la transizione e i risultati.

Secondo Milind Wagle, CIO di Equinix, impegnato in questa transizione, un punto fondamentale è stabilire quale reparto “è proprietario un determinato prodotto”, perché questo definisce “i ruoli e le responsabilità nel modello operativo”.

Tali dettagli – il dipartimento responsabile e i ruoli personali – possono sembrare ostacoli abbastanza semplici da superare. Ma, secondo gli esperti, sono tipici delle organizzazioni che migrano verso operazioni basate sul prodotto, che richiedono una governance diversa rispetto agli approcci di gestione del progetto.

“Il passaggio dal progetto al prodotto è un cambiamento epocale”, afferma Remi Gulzar, analista di Gartner. “Ridistribuisce e mette in discussione decisioni, diritti e responsabilità”.

Ciononostante, i CIO scelgono la gestione basata sui prodotti per la sua capacità di rendere le operazioni agili e in grado di cambiare rapidamente secondo le esigenze. Attirati dalla promessa di guidare l’innovazione continua che si tradurrà in un vantaggio competitivo, il 40% delle grandi imprese gestirà le capacità aziendali interne come prodotti entro il 2023, secondo una ricerca di Gartner.

Project management vs product management

La gestione del progetto e la gestione del prodotto presentano differenze e sovrapposizioni. I progetti tendono a coprire le iniziative “Big Bang”, come l’implementazione di un nuovo sistema ERP o un cambiamento importante nei processi, per esempio il passaggio dall’inserimento manuale dei dati all’automazione robotica dei processi (RPA). Secondo Gulzar, i prodotti possono includere funzionalità di business digitale o flussi di valore, nonché prodotti che sono preziosi per uno specifico segmento di clienti. Un prodotto interno potrebbe includere un’applicazione che facilita le transazioni senza contatto; un prodotto esterno potrebbe includere un’applicazione mobile progettata per consentire ai clienti di acquistare beni o servizi realizzati dal brand.

Nella tradizionale gestione del progetto, il finanziamento è previsto per la durata di un progetto in base alle risorse e al tempo. Anche i prodotti vengono finanziati per il loro ciclo di vita, ma in base alle esigenze aziendali. Il lavoro sui progetti termina a una data fissa, mentre i prodotti vengono continuamente perfezionati fino a quando non vengono ritirati dal mercato. I progetti evitano il cambiamento, mentre i prodotti accettano il cambiamento, se necessario. I progetti vengono definiti in base a obiettivi, mentre i prodotti vengono sincronizzati in base al valore che forniscono all’attività.

Per quanto riguarda lo sviluppo, la maggior parte dei progetti viene ancora realizzata con metodologie a cascata, prevede requisiti definiti dal business e viene consegnata all’IT per il completamento. I prodotti sono spesso realizzati da team composti da personale IT e del business, che utilizzano uno sviluppo software agile. Ma nel mondo in evoluzione del product management, la proprietà è diventata un punto critico per alcune aziende, per quanto controproducente possa essere.

Nella maggior parte dei modelli di gestione dei progetti, gli stakeholder aziendali sono “proprietari” dei progetti, trasmettendo ordini di servizio all’IT e determinando i cicli di consegna. L’impostazione è diversa nel modello incentrato sul prodotto, in cui la proprietà è sempre più condivisa. “In alcuni scenari, la proprietà del prodotto può essere ridistribuita nell’IT, apportando capacità critica e conoscenza del prodotto”, afferma Diana Bersohn, managing director della strategia tecnologica di Accenture. “Il confine tra IT e business non è più così importante”.

La proprietà può sembrare secondaria rispetto al raggiungimento di un obiettivo aziendale, ma crea confusione tra i dipendenti abituati a lavorare con modelli di gestione del progetto. Di fatto, la strada per la gestione del prodotto è lastricata di insidie.

Le difficoltà nella gestione basata sul prodotto

“Le aziende che corrono senza fiato verso la gestione basata sul prodotto commettono alcuni passi falsi comuni”, afferma Art Hu, che sta abbracciando un modello operativo basato sul prodotto come CIO di Lenovo.

Alcuni team eseguono sprint senza stabilire una base, mettendo insieme qualcosa che non si traduce in un prodotto. I team di prodotto hanno bisogno di intenti e risultati ben definiti, nonché di parametri di riferimento per tenere sotto controllo lo sviluppo del lavoro. “Senza questi riferimenti, si rischia di ritrovarsi in diversi vicoli ciechi”, dice Hu.

Un altro problema sorge quando l’IT o il business sviluppano un prodotto senza consultarsi a vicenda. “Ciò può rendere la governance confusa, un problema che si aggrava man mano che i modelli di coinvolgimento si espandono per incorporare più parti interessate, ognuna delle quali desidera massimizzare l’efficacia“, afferma Gulzar.

Un esempio di successo. Il team di Hu ha lavorato a stretto contatto con i team aziendali e finanziari per creare un nuovo sistema CRM globale in Microsoft Dynamics. Il software cloud è nato come un progetto con un budget e una data di consegna fissati prima di diventare un prodotto che viene regolarmente perfezionato e migliorato, in quello che Hu descrive come un “percorso di apprendimento” che i team Lenovo stanno intraprendendo insieme.

I membri del team hanno inoltre acquisito così tante conoscenze ed esperienze che sono diventate patrimonio di tutta l’azienda. “L’effetto positivo netto è stato consentire ai team di sviluppare competenze ed essere riconosciuti in modo da poter promuovere la transizione dal progetto al prodotto”, sottolinea Hu.

Il CIO di Lenovo afferma che l’aspetto più importante della gestione del prodotto è assicurarsi che tutti siano chiari sul “perché lo stiamo facendo”, altrimenti non può sperare di ottenere il risultato desiderato. “Soddisfa le esigenze dei clienti? Aiuterà a raggiungere una crescita del mercato a due cifre? Queste sono le domande che il CIO dovrebbe porsi”, secondo Hu.

La gestione del prodotto richiede una governance flessibile

Non esiste un percorso univoco per il successo, ma Gulzar consiglia alle aziende di supportare modelli operativi incentrati sul prodotto sostituendo una governance unica per tutti con una governance flessibile che contestualizza i diritti decisionali bilanciando le esigenze del prodotto con gli obiettivi aziendali. Idealmente, i CIO passeranno da un modello basato sul controllo a uno basato sul raggiungimento dei risultati desiderati.

Gulzar consiglia inoltre ai CIO di impegnarsi con i proprietari dei prodotti per creare diritti decisionali distribuiti che determinano l’uso della tecnologia sia a livello aziendale che di prodotto. Inoltre, i CIO dovrebbero aiutare i proprietari del prodotto a sviluppare le competenze necessarie per bilanciare le esigenze di sviluppo con gli obiettivi e i vincoli aziendali e fare affidamento sulla gestione del cambiamento per superare le tensioni naturali tra IT, gestione del prodotto e business. Tale approccio “permette di aprire la porta al dialogo, piuttosto che chiuderla”, aggiunge.

Il ruolo del CIO nel passaggio al modello di product management

Indipendentemente dal percorso che i leader IT stanno intraprendendo verso modelli incentrati sul prodotto, “il ruolo del CIO si è spostato a un ruolo orientato al business incentrato sulla co-creazione con il business”, afferma Wagle.

Per sostenere questo cambiamento in Equinix, Wagle sta dando la priorità a un programma per migliorare le capacità di comunicazione dei suoi leader. “Cerchiamo di creare ‘mini-CEO’ all’interno dell’azienda”, conclude Wagle. “In questo modo i leader IT acquisiscono credibilità e possono diventare driver di trasformazione, e non limitarsi all’implementazione di progetti”.