Come consegnare un progetto di innovazione da una squadra all’altra

Articolo tradotto tratto da Harvard Business Review

“How to Hand Off an Innovation Project from One Team to Another” di Joe Brown

Fonte: https://hbr.org/2018/08/how-to-hand-off-an-innovation-project-from-one-team-to-another 

Quasi tutti i leader che ho incontrato hanno a che fare con la paura di essere superati dalle avanguardie tecnologiche. Questa paura spinge le loro aziende a investire milioni in innovazioni rivoluzionarie. Ma un numero enorme di quegli investimenti fallisce. La verità è che puoi disporre del giusto portafoglio di investimenti, delle giuste metriche e governance, del giusto processo di sviluppo e del talento giusto nei team giusti – ma se non si progettano correttamente i flussi tra i team, tutta la pianificazione crolla.
Se i progetti di innovazione sono destinati ad avere successo, dovranno sopravvivere al passaggio da un team di innovazione ad un team di esecuzione. E ogni volta che si realizza un trasferimento, si rischia di perdere il testimone.

Ecco un esempio. Una delle principali società di elettronica asiatica ha costruito un laboratorio di progettazione per sviluppare nuove idee sui prodotti hardware. Troppo spesso, quando il laboratorio di progettazione trasmetteva un’idea ad un Product Manager, come un computer personalizzato per i modellatori 3D e gli editor di film, il PM ignorava il pensiero del laboratorio e applicava semplicemente il design fisico del computer a un prodotto che era già in via di sviluppo – come un computer a bassa potenza destinato agli studenti per il ritorno a scuola. Quando le vendite del prodotto Frankenstein hanno fallito l’obiettivo, tutti hanno condiviso la colpa. Questa società di elettronica non aveva un piano chiaro su come i progetti dovessero passare dal team del piccolo laboratorio di progettazione al core business. Più che un passaggio di consegne, era una cascata.

Come si previene un drop-off? Adattando ciascun trasferimento alle squadre coinvolte. In molte aziende, i team di innovazione tendono a dividersi in tre categorie: esploratori, scalatori e ottimizzatori (citando Bud Caddell e Simon Wardley). Gli ottimizzatori costituiscono il nucleo delle attività più consolidate: sono esperti nel migliorare e perfezionare l’attività esistente per promuovere la crescita o migliorare le operazioni. Gli esploratori lavorano nei team ricerca e sviluppo, ricerche sul cliente o sviluppo del prodotto. Gli esploratori sono abili a scoprire nuove opportunità davanti all’ambiguità: sono persone che traducono l’ispirazione in idee usando metodi come il design thinking. Gli scalatori sperimentano e modificano ciclicamente le nuove idee fino a quando non trovano l’incastro perfetto tra prodotto e mercato. Queste etichette descrivono anche le fasi dell’innovazione:

1. Esplora
2. Scala
3. Ottimizza

Come si facilita un passaggio tra team? Ci sono quattro modelli base per il trasferimento e dozzine di ibridi. La soluzione giusta per ogni parte del tuo processo di innovazione dipenderà da quanto i tuoi progetti debbano essere integrati con il tuo core business.

Il Manuale delle istruzioni

Questo è sia il metodo di passaggio più comune sia il più difficile da realizzare. Dopo mesi, a volte anni di lavoro, un team di innovazione documenta ampiamente il proprio lavoro in centinaia di pagine di diapositive, fogli di lavoro e altri file, quindi passa tutto a un nuovo team per farlo eseguire. Quando è stata l’ultima volta che hai letto un manuale di istruzioni? Esattamente. Basta estrarre il Manuale d’uso.
In questo modello, una ingente quantità di lavoro viene dimenticata. La nuova squadra quindi rischia di andare avanti senza assorbire le conoscenze dei loro predecessori. Questo modello funziona meglio quando non vi è più ambiguità nella sfida, quando il progetto è pronto per essere implementato dai team tecnici e quando il manuale può essere suddiviso in capitoli piccoli, specifici e attuabili per ciascuno dei suoi stakeholder.

L’architetto

Il modo migliore per evitare un drop-off è eliminare il trasferimento. In questo modello, il futuro project owner si incorpora nei team di Explorer e Scaler. Agisce quindi come un connettore, conoscendo tutte le vie già esplorate e tutte le conoscenze acquisite. Questo è un modello fondamentale per industrie produttrici di beni di consumo, dove una persona, ad esempio il brand manager, è responsabile dello sviluppo del prodotto dall’inizio alla fine. Anche se l’architetto potrebbe non gestire il progetto in ogni fase, sarà necessario avere la sua approvazione finale sul lavoro del team. Se l’architetto non crede nel lavoro, finirà per uccidere l’idea.

Gli ambasciatori

Analogamente al modello precedente, in questo modello i membri dei team Explorer, Scaler e Optimizer rimangono integrati in ciascuna fase del progetto per garantire che non venga perso alcun apprendimento e che ogni fase del lavoro sia progettata per agevolare la successiva. Inoltre, questo modello migliora il lavoro futuro dei team aiutandoli a costruire una consapevolezza di ciò che necessitano i team a valle. Questo modello è più comune nei team di sviluppo software, dove i progettisti possono essere coinvolti sia nella ricerca iniziale dell’utente che nella gestione a lungo termine del prodotto.

L’alveare

In questo modello, team multidisciplinari affrontano le sfide lungo l’intero ciclo di vita dell’iniziativa. Questo è più comune negli acceleratori e negli incubatori, in cui la nuova organizzazione viene impostata come una partizione della società madre e costituita da persone di tutte le principali funzioni e discipline. I team dell’alveare hanno anche rappresentanti di funzioni che normalmente potrebbero agire come anticorpi aziendali, come legale, finanziario, risorse umane. L’alveare spinge quelle funzioni a mutare atteggiamento, passando da una posizione di eliminazione del rischio a una di riduzione dello stesso.

Al di fuori del Manuale d’uso, ciascuno degli altri modelli di handoff guida i team di implementazione lungo tutto il processo di innovazione per consentire senza problemi il passaggio di conoscenza. In questo modo si riduce la sensazione di non paternità dell’idea, rendendo l’handoff più simile a dei sorsi d’acqua costanti e regolari che non ad una cascata.