Sei miti da sfatare nello sviluppo di nuovi prodotti

Quasi tutti i responsabili dello sviluppo di nuovi prodotti faticano regolarmente a concludere i progetti nei tempi previsti e nel rispetto del budget. Non hanno mai abbastanza risorse per portare a termine il progetto e i loro capi esigono una programmazione rigorosa e risultati concreti. Di conseguenza, questi manager invitano i collaboratori a essere più parsimoniosi, a predisporre piani più dettagliati e a minimizzare gli sforamenti e gli sprechi. Ma questo approccio, che potrebbe funzionare bene quando si devono ristrutturare delle fabbriche inefficienti, rischiano in realtà di pregiudicare lo sviluppo di nuovi prodotti.

Anche se molte aziende assimilano sostanzialmente lo sviluppo di nuovi prodotti alla produzione, i due processi sono profondamente diversi. Nel mondo della produzione industriale, i compiti sono ripetitivi, le attività sono ragionevolmente prevedibili e gli articoli realizzati possono trovarsi in un solo posto alla volta. Nello sviluppo di nuovi prodotti molti compiti sono unici, le specifiche di progetto si modificano costantemente e l'output - anche grazie al diffuso utilizzo del CAD avanzato, della simulazione e dell'incorporazione del software nei prodotti fisici - consiste in informazioni, che possono risiedere in più luoghi nello stesso tempo.

Il mancato apprezzamento di queste differenze critiche ha dato origine a una serie di false credenze che pregiudicano la pianificazione, l'esecuzione e la valutazione dei progetti di sviluppo di nuovi prodotti. Mettendo assieme le nostre esperienze, abbiamo trascorso più di cinquant'anni a studiare e a consigliare le aziende sullo sviluppo di nuovi prodotti e abbiamo incontrato queste idee sbagliate - e altre che si determinano per ragioni di diverso tipo - in una vasta gamma di settori, tra cui i semiconduttori, le automobili, l'elettronica di consumo, gli apparecchi elettromedicali, il software e i servizi finanziari. In questo articolo li illustreremo e proporremo delle soluzioni per superare i problemi che pongono.

FALSA CREDENZA N. 1

L'elevato utilizzo delle risorse migliora la performance.

Abbiamo visto, sia nelle ricerche sia nelle nostre consulenze, che la stragrande maggioranza delle aziende tenta di sfruttare al massimo le proprie risorse di sviluppo prodotti. (Attraverso le indagini effettuate nei corsi per i dirigenti che teneva presso il California Institute of Technology, uno di noi, Donald, ha scoperto che il responsabile medio dello sviluppo di nuovi prodotti mantiene il tasso di utilizzo della capacità operativa al di sopra del 98%). La logica sembra ovvia: i progetti portano via più tempo quando le persone non lavorano su di essi al 100% del tempo – e, di conseguenza, un'organizzazione di sviluppo totalmente saturata sarà più rapida ed efficiente di un'organizzazione corrispondente che non è altrettanto brava a utilizzare i propri collaboratori.

Ma nella pratica questa logica non funziona. Abbiamo constatato che la velocità, l'efficienza e la qualità dell'output dei progetti si riducono inevitabilmente quando i manager - indipendentemente dalla loro competenza - saturano totalmente la capacità lavorativa degli addetti allo sviluppo di nuovi prodotti. L'elevato utilizzo ha seri effetti collaterali negativi, che i manager tendono a sottovalutare per tre ragioni:

Non tengono pienamente conto della variabilità intrinseca nell'attività di sviluppo. Molti aspetti dello sviluppo di nuovi prodotti sono imprevedibili: quando arriveranno i progetti, quali compiti individuali richiederanno e quanto ci metteranno a svolgerli dei dipendenti che non hanno mai affrontato compiti di questo tipo. Le aziende, tuttavia, hanno maggiore familiarità con processi ripetitivi come la produzione e la gestione delle transazioni, dove il lavoro non cambia granché e le sorprese sono poche e molto distanziate nel tempo. Questi processi operano in maniera prevedibile all'aumentare del tasso di utilizzo delle risorse: aumentate il lavoro del 5% e ci vorrà un 5% di tempo in più per portare a termine il progetto.

I processi ad alta variabilità si comportano in maniera molto diversa. All'aumentare del tasso di utilizzo, i ritardi si allungano enormemente. (Si veda la figura "L'elevato utilizzo causa dei ritardi"). Aggiungete un 5% in più di lavoro, e i tempi di completamento possono raddoppiarsi. Ma pochi conoscono questo effetto. Nell'esperienza che abbiamo maturato con centinaia di team di sviluppo prodotti, abbiamo scoperto che erano quasi tutti sovraccarichi di lavoro. Per completare tutti i progetti nei tempi previsti nel rispetto del budget, alcune organizzazioni con cui abbiamo lavorato avrebbero dovuto avere almeno il 50% di risorse in più.

È vero che la variabilità dipende anche dalla mancanza di disciplina e che alcuni compiti di sviluppo prodotti (come la progettazione dei componenti per il prototipo di un aeroplano o la sperimentazione clinica) includono un lavoro più ripetitivo. Ma anche se una parte del lavoro è prevedibile, quando si combina con altre attività imprevedibili si creano sempre delle code.

Non capiscono come incidono le code sulla performance economica. L'elevato utilizzo delle risorse crea inevitabilmente delle code di progetti. Quando un lavoro parzialmente completato resta fermo in attesa di nuova capacità operativa, la durata del progetto complessivo si allunga. Le code ritardano anche il feedback, costringendo gli sviluppatori a seguire più a lungo dei percorsi improduttivi. Impediscono alle imprese di adattarsi ai nuovi bisogni del mercato e di rilevare i punti deboli del prodotto prima che sia troppo tardi. Curiosamente, questi problemi sono proprio gli stessi che secondo i manager un elevato utilizzo delle risorse dovrebbe contribuire a evitare.

Anche quando si rendono conto di creare delle code, i manager non si rendono quasi mai conto del costo economico. E pur trattandosi di un costo quantificabile, abbiamo scoperto che la stragrande maggioranza delle aziende non lo calcola. I manager devono soppesare i costi delle code e i costi della capacità sottoutilizzata per trovare il giusto equilibrio.

Nello sviluppo dei prodotti, le code di lavorazione sono prevalentemente invisibili. Le code di produzione consistono di cose materiali e quando le scorte di una fabbrica raddoppiano, si vede. Non è così nello sviluppo dei prodotti, dove le "scorte" di semilavorati, ossia le code di lavorazione, consistono prevalentemente in informazioni, come la documentazione sul progetto, le procedure e i risultati dei test, e le istruzioni per la costruzione di prototipi. Quando le scorte raddoppiano in un processo di engineering, non ci sono evidenze fisiche in questo senso. Inoltre, poiché gli standard contabili prevedono che la maggior parte delle giacenze legate all'R&S vengano contabilizzate a valore zero, i bilanci non danno alcuna indicazione di significativi eccessi "di magazzino" nello sviluppo di nuovi prodotti.

È molto difficile cercare di risolvere un problema che non si può vedere o misurare. Prendete il caso di una grande azienda farmaceutica. Alcuni anni fa il neo nominato capo della ricerca si è trovato di fronte a un dilemma manageriale. Come altri top manager che gestiscono grandi organizzazioni di R&S, cercava la maniera di rendere più innovativi i suoi ricercatori. Voleva che sperimentassero maggiormente dei nuovi composti chimici in grado di generare nuovi farmaci promettenti e, nel contempo, di eliminare il più presto possibile quelli poco promettenti. Gli esperimenti sugli organismi viventi, tuttavia, competevano alla funzione "animal testing", che non era sotto il suo controllo e veniva gestita come centro di costo. Veniva valutata in base all'efficienza con cui usava le risorse destinate alla sperimentazione, il che favoriva naturalmente un elevato utilizzo. Di conseguenza, i ricercatori dovevano aspettare tre o quattro mesi per avere i risultati di esperimenti che duravano poco più di una settimana. La "ben gestita" funzione animal testing impediva all'unità di ricerca di fare progressi.

L'ovvia soluzione a questi problemi è mettere a disposizione una riserva di capacità nei processi altamente variabili. Alcune aziende lo hanno capito da tempo. Da vari decenni, la 3M fa lavorare gli sviluppatori di nuovi prodotti all'85% della loro capacità. E Google è famosa per la regola del "20% del tempo" (che consente agli ingegneri di lavorare un giorno alla settimana su ciò che vogliono - e mette a disposizione della capacità addizionale se un progetto è in ritardo sulla tabella di marcia). Ma nella nostra esperienza, una soluzione di questo tipo è di difficile implementazione. Come vedremo, poche organizzazioni sanno resistere alla tentazione di usare il 100% della capacità disponibile. Quando percepiscono la non-saturazione delle risorse, i manager creano automaticamente altro lavoro.

Ma ci sono altre soluzioni valide:

Modificare i sistemi di controllo manageriale. Per l'azienda farmaceutica citata in precedenza, ciò potrebbe comportare il tentativo di allineare gli obiettivi della funzione animal testing agli obiettivi dell'unità di ricerca. L'azienda potrebbe, per esempio, premiare l'animal testing in base alla rapidità delle risposte (misurata in base al tempo intercorso tra la richiesta e il completamento del test) anziché all'utilizzo delle risorse.

Incrementare selettivamente la capacità. Aggiungendo altre risorse nelle aree in cui i tassi di utilizzo sono del 70% o superiori, si possono ridurre sensibilmente i tempi di attesa. Se la casa farmaceutica lo facesse nell'animal testing, otterrebbe molto prima il feedback sui nuovi composti chimici. Nei contesti in cui la sperimentazione viene effettuata con la modellizzazione e la simulazione al computer, aumentare la capacità è spesso relativamente poco costoso, perché basta acquistare altri computer e altre licenze software.

Limitare il numero dei progetti attivi. Se la casa farmaceutica non fosse in grado di aumentare la capacità dell'animal testing, potrebbe sempre abbassare il tasso di utilizzo riducendo il numero dei progetti attivi per l'esplorazione dei nuovi composti chimici. La disciplina che impone un limite numerico ai progetti di sviluppo si traduce spesso in una maggiore focalizzazione e in una migliore definizione delle priorità.

Rendere più visibili le code di lavorazione. Un metodo potrebbe essere l'utilizzo di schede di controllo. Queste schede possono assumere svariate forme, ma l'importante è fare in modo che un simbolo fisico, come un foglietto adesivo, venga a rappresentare il lavoro di sviluppo (si veda la figura "Una tipica scheda di controllo delle code di lavorazione"). La scheda di controllo dovrebbe mostrare tutti i progetti attivi e lo status di ogni parte del progetto. Dovrebbe essere al centro del processo di gestione del team. I team di sviluppo possono tenere ogni giorno riunioni di un quarto d'ora incentrate su queste schede per coordinare gli sforzi e portare avanti efficacemente il lavoro.

FALSA CREDENZA N. 2

Operando in grossi lotti si migliora l'efficienza del processo di sviluppo.

Una seconda causa della formazione di code nello sviluppo di nuovi prodotti è la dimensione del lotto. Supponiamo che un nuovo prodotto contenga 200 componenti. Potreste decidere di progettare e costruire tutti i 200 componenti prima di testarli. Se invece ne progettaste e ne costruiste solo 20 prima di iniziare la sperimentazione, la dimensione del lotto sarebbe inferiore del 90%. Ciò avrebbe un effetto sostanziale sul tempo di attesa, perché la coda media in un processo è direttamente proporzionale alla dimensione del lotto.

Il ridimensionamento dei lotti è un principio fondamentale di produzione snella. Dei lotti piccoli consentono ai produttori di ridurre le code di lavorazione e di accelerare il feedback, il che a sua volta migliora i tempi-ciclo, la qualità e l'efficienza. I piccoli lotti sono ancora più utili nello sviluppo dei prodotti, ma pochi sviluppatori comprendono l'efficacia di questo metodo.

Ciò si deve anzitutto alla natura del loro flusso operativo. E siccome le informazioni che producono sono generalmente invisibili per loro, lo sono anche le dimensioni dei lotti. In secondo luogo, gli sviluppatori sembrano avere un orientamento preconcetto all'utilizzo di grandi lotti - probabilmente perché credono, erroneamente, che producano economie di scala.

In un processo ben gestito, la dimensione del lotto metterà in equilibrio costi di transazione e costi di immobilizzazione (si veda la figura "Come determinare la dimensione ottimale del lotto"). È un po' come comprare le uova al supermercato. Se acquistate in una volta sola la fornitura di un anno il vostro costo di transazione è basso, ma la maggior parte delle uova andranno a male, facendo lievitare i costi di immobilizzazione. Se acquistate il fabbisogno giornaliero ogni volta che andate al supermercato, il deterioramento delle uova sarà basso, ma i vostri costi di transazione saranno alti. A livello intuitivo, cercate automaticamente di trovare un equilibrio tra le due cose.

Le aziende che comprendono questo meccanismo hanno sfruttato i progressi dell'IT per ridurre le dimensioni dei lotti, spesso con risultati eclatanti. Alcune aziende di software che erano abituate a testare grossi batch di codifica ogni 90 giorni, oggi testano batch molto più piccoli più volte al giorno. Un produttore di periferiche per computer che usava un approccio analogo con il suo team di programmazione ha ridotto il tempo-ciclo di sperimentazione del software del 95% (da 48 mesi a 2,5 mesi), ha migliorato l'efficienza del 220% e ha ridotto i difetti del 33%. I risparmi sono stati doppi rispetto alle attese dell'azienda. Pur trattandosi di risultati eccezionali, abbiamo scoperto che riducendo la dimensione dei lotti si migliorano significativamente quasi tutti i progetti di sviluppo. Analogamente, gli strumenti di modellizzazione e simulazione al computer hanno abbassato drasticamente la dimensione del lotto ottimale di sperimentazione e testing in aziende che sviluppano prodotti fisici.

FALSA CREDENZA N. 3

II nostro piano di sviluppo è perfetto; dobbiamo solo rispettarlo.

Nel nostro lavoro di consulenza e nella nostra attività di ricerca, non abbiamo mai incontrato un solo progetto di sviluppo di un nuovo prodotto i cui requisiti siano rimasti stabili per tutta la durata del processo di progettazione. Eppure molte organizzazioni ripongono una fiducia smisurata nei propri piani. Attribuiscono tutti i possibili scostamenti a una cattiva gestione e a una esecuzione inadeguata, e per minimizzarli, misurano accuratamente tutte le fasi rispetto a target intermedi e pietre miliari. Questa logica va benissimo per delle attività altamente ripetitive che si svolgono all'interno di processi produttivi consolidati. Ma può portare a risultati scadenti nell'innovazione di prodotto, dove si fanno ogni giorno nuove scoperte e le condizioni sono in continua evoluzione.

Un celebre studio sul problema solving tecnico condotto da Thomas Allen del MIT mette in luce la natura fluida dell'attività di sviluppo. Allen ha scoperto che gli ingegneri impegnati nello sviluppo di un sottosistema aerospaziale concepivano e valutavano tutta una serie di alternative di progettazione prima di sceglierne una che giudicavano la migliore. E in corso d'opera le loro preferenze si modificavano frequentemente, man mano che testavano e affinavano soluzioni tecniche in competizione tra loro. È un andamento tipico dei progetti di innovazione: il testing e la sperimentazione rivelano ciò che funziona e ciò che non funziona, e gli assunti iniziali sui costi e sul valore potrebbero essere confutati.

Anche definire i bisogni dei clienti può essere problematico all'inizio di un progetto di sviluppo di un nuovo prodotto. Se ci pensate, non è affatto sorprendente: non è facile per i clienti specificare i propri bisogni, relativamente a soluzioni che non esistono ancora. In effetti, la familiarità con le caratteristiche dei prodotti in essere può interferire con la capacità di un individuo di esprimere il bisogno di un prodotto innovativo. Le preferenze dei clienti possono anche mutare repentinamente nel corso di un progetto di sviluppo, nel momento in cui i concorrenti introducono nuove offerte ed emergono nuovi trend.

Per tutte queste ragioni, restare fedeli al piano originario - per eccellente che sia la concezione e per abile che sia l'esecuzione - può essere la ricetta di un disastro. Ciò non significa che non crediamo nella pianificazione. Lo sviluppo di un nuovo prodotto è una serie di attività complesse che richiedono un accurato coordinamento e l'attenzione ai minimi dettagli. Ma il piano andrebbe considerato un'ipotesi iniziale che viene costantemente rivista man mano che si accumulano le evidenze empiriche, si modificano gli assunti economici e si rivaluta l'opportunità. (Si veda l’articolo "I processi per estrarre il valore", di Rita Gunther McGrath e Thomas Keil, HBR giugno 2007).

FALSA CREDENZA N. 4

Prima si avvia il progetto, prima verrà completato.

Come dicevamo prima, i tempi morti sono una bestemmia per i manager, che tendono a sfruttare ogni momento di "stanca" per avviare un nuovo progetto. Anche se il compito non si può completare perché le persone devono rimettersi a lavorare su un altro progetto, i manager si dicono che qualunque avanzamento del nuovo progetto è un lavoro che non si dovrà fare più avanti. Questo modo di ragionare spinge le aziende ad avviare più progetti di quelli che possono gestire efficacemente, diluendo le risorse.

La diluizione è pericolosa. Se un'azienda si imbarca in un progetto prima di avere le risorse necessarie per andare avanti, il processo di sviluppo procederà a rilento. È un fatto problematico perché lo sviluppo del prodotto è altamente deperibile: gli assunti sulle tecnologie e sul mercato possono andare rapidamente in obsolescenza. Più lentamente avanza un progetto, maggiore è la probabilità che si debba ri-orientare. Una branca delle forze armate ha scoperto che gli sforamenti del budget e della tempistica erano esponenzialmente proporzionali (alla quarta potenza) rispetto alla durata del progetto. In altre parole, quando la tempistica originaria di un progetto  raddoppiava, i costi e i ritardi si moltiplicavano per 16.

L'importanza di minimizzare il carico di lavoro insito nel processo diventa evidente se guardiamo a una delle formule classiche della teoria delle code: la legge di Little. Essa afferma semplicemente che, in media, il tempo-ciclo è proporzionale alla dimensione della coda divisa per il tasso di processazione. Così, se da Starbucks ci sono 20 persone in coda prima di voi e il barista ne serve cinque al minuto, voi verrete serviti tra quattro minuti. Potete abbreviare il tempo-ciclo aumentando il tasso di processazione o riducendo il numero di compiti da svolgere. Nella maggior parte dei contesti, la seconda è l'unica scelta praticabile.

Per alcuni sviluppatori di prodotti, la soluzione è stata quella di controllare rigorosamente il ritmo a cui iniziano a lavorare. Poi lo confrontano con il ritmo a cui viene effettivamente completato il lavoro; gestiscono attentamente il numero dei progetti in corso; fanno in modo che una volta lanciato, un progetto venga adeguatamente supportato in termini di staff fino al completamento e resistono alla tentazione di sottrarre risorse a un progetto in corso per infilarne di nuovi nel programma.

FALSA CREDENZA N. 5

Più caratteristiche mettiamo in un prodotto, più i clienti lo apprezzeranno.

I team di sviluppo di nuovi prodotti sembrano convinti che aggiungendo ulteriori caratteristiche si crei valore per i clienti e che sottraendone si distrugga valore. Questo atteggiamento spiega perché i prodotti sono così complicati: i telecomandi sembrano impossibili da usare, i computer ci mettono ore ad avviarsi, le automobili hanno talmente tanti interruttori e manette da assomigliare alle cabine di pilotaggio degli aerei, e oggi persino l'umile tostapane ha un manuale di istruzione e dei display a cristalli liquidi.

Le aziende contrarie alla diffusa convinzione che più caratteristiche siano sinonimo di migliore qualità creano dei prodotti che sono eleganti nella loro semplicità. Bang & Olufsen, l'azienda danese che produce sistemi audio, televisori e telefoni di alta gamma, si rende conto che non necessariamente i clienti vogliono smanettare con l'equalizzatore, il balance e altri comandi per trovare la combinazione ottimale delle opzioni di ascolto della musica. I suoi altoparlanti ultrasofisticati fanno automaticamente gli aggiustamenti necessari per riprodurre una canzone nel modo più fedele possibile rispetto all'originale. Gli utilizzatori devono solo scegliere il volume.

Indurre le aziende ad accettare e a incrementare il principio che meno caratteristiche possono dare più valore è difficile, perché occorre uno sforzo aggiuntivo in due aree del processo di sviluppo dei prodotti:

Definire il problema. Formulare il problema che gli sviluppatori tenteranno di risolvere è la parte più sottovalutata del processo di innovazione. Troppe aziende vi dedicano un tempo insufficiente. Ma è una fase importante, perché è qui che i team stabiliscono chiaramente quali sono i propri obiettivi e generano ipotesi che si possono testare e affinare con degli esperimenti. La qualità della definizione di un problema fa tutta la differenza nella capacità di un team di focalizzarsi sulle nuove caratteristiche che contano davvero.

Quando Walt Disney ha progettato Disneyland, non si è preoccupato di aggiungere ulteriori caratteristiche (attrazioni, varietà di cibo, parcheggi) già presenti in altri parchi dei divertimenti. Si è posto anzitutto una domanda di portata molto più vasta: come fornire ai visitatori un'esperienza magica? Certo, la risposta non è arrivata da un giorno all'altro; ci sono volute ricerche minuziose, una sperimentazione costante e una analisi approfondita di ciò che significava "magico" per la Disney e i clienti. IDEO e altre aziende hanno delle fasi programmate in cui si immergono completamente nel contesto in cui verrà usato il prodotto o il servizio allo studio. I loro sviluppatori leggono tutto ciò che può esservi di interessante sui mercati, osservano e intervistano dei futuri utilizzatori, analizzano le offerte che andranno a competere con il nuovo prodotto e sintetizzano tutto ciò che hanno appreso in immagini, modelli e diagrammi. Il risultato è una serie di conoscenze approfondite sui clienti che vengono testate, migliorate o abbandonate attraverso il processo iterativo di sviluppo.

Decidere che cosa nascondere od omettere. I team provano spesso la tentazione di mettersi in mostra producendo brillanti soluzioni tecniche che stupiscono i colleghi e il management. Ma i clienti preferirebbero spesso un prodotto che si limita a funzionare bene. Dal punto di vista del cliente, le soluzioni migliori sono quelle che risolvono un problema nel modo più semplice e nascondono il lavoro di cui gli sviluppatori vanno tanto fieri.

Un'azienda che ha capito questo principio è Apple. È famosa per molte cose – dei prodotti innovativi, un design accattivante e un marketing efficace - ma il suo maggior punto di forza è probabilmente la capacità di andare al cuore di un problema. (Si veda "Le vere lezioni di leadership di Steve Jobs", di Walter Isaacson, nel nostro numero di aprile). Come spiegava il compianto Steve Jobs, «quando cominci a esaminare un problema e ti sembra veramente semplice, vuol dire che non capisci la sua complessità. E le tue soluzioni sono decisamente iper-semplificate. Poi entri nel problema e ti rendi conto che è veramente complicato. Allora escogiti tutte quelle soluzioni astruse … È qui che si fermano quasi tutti». Ma non Apple, che continua a perseverare. «Il vero grande manager continuerà a insistere», diceva Jobs, «finché non scoprirà il principio fondamentale che sta alla base del problema ed escogiterà una soluzione bella ed elegante, in grado di funzionare».

Stabilire quali caratteristiche omettere è importante come decidere quali includere. Sfortunatamente, molte aziende, nel tentativo di essere innovative, inseriscono nel prodotto tutti i possibili gadget senza tenere pienamente conto di fattori importanti come il valore per i clienti e la facilità d'uso. Quando queste aziende omettono una funzionalità pianificata, lo fanno quasi sempre perché devono ridurre i costi o sono in ritardo sul programma, o perché il team ha fallito in qualche altro modo.

Invece, il manager dovrebbero concentrarsi sul tentativo di scoprire se la rimozione di una caratteristica in programma non potrebbe migliorare un determinato prodotto o consentire al team di concentrarsi su aspetti che potrebbero veramente migliorare l'esperienza complessiva del cliente. Ciò si può stabilire trattando ogni presunto requisito come una semplice ipotesi e mettendola alla prova in piccoli esperimenti veloci sui potenziali clienti.

I team di sviluppo assumono spesso che i loro prodotti siano completi quando non si possono più aggiungere altre caratteristiche. Forse dovrebbero invertire quella logica: i prodotti si avvicinano maggiormente alla perfezione quando non si possono più eliminare delle caratteristiche. Come disse Leonardo da Vinci, «la semplicità è il massimo della sofisticatezza».

FALSA CREDENZA N. 6

Avremo più successo se partiamo da subito con il piede giusto.

Molti progetti di sviluppo di nuovi prodotti non raggiungono gli obiettivi fissati a livello di budget, di tempistica e di performance tecnica. Una pianificazione inadeguata, dei processi rigidi e una leadership debole hanno indubbiamente il loro peso. Ma un'altra causa che viene trascurata frequentemente è la pretesa dei manager che i loro team "partano da subito con il piede giusto". Pretendendo il successo immediato si finisce con l’orientare i team verso le soluzioni meno rischiose, anche se i clienti non le considerano un miglioramento significativo rispetto a ciò che è già disponibile. E peggio ancora, i team hanno pochissimi incentivi a perseguire soluzioni innovative ai problemi dei clienti.

Per evitare di commettere errori, i team seguono un processo lineare in cui ogni fase (definizione delle specifiche, progettazione, costruzione, test, estensione, lancio) viene attentamente monitorata al raggiungimento di determinati "cancelli". Il lavoro sulla fase successiva non può iniziare finché un progetto non supera il cancello. A quel punto si prendono impegni significativi e il costo di applicazione di nuove soluzioni cresce esponenzialmente. I test riusciti nelle fasi successive vengono festeggiati e le sorprese, per preziose che possano essere, si considerano battute d'arresto. Sfortunatamente, questo flusso lineare di processo può causare degli sforamenti rispetto al budget e alla tempistica del progetto perché il feedback sul test viene ritardato, i team rimangono affezionati più a lungo del dovuto a delle idee inadatte e i problemi non vengono scoperti finché non diventa particolarmente costoso risolverli.

Una certa tolleranza per l'insuccesso iniziale può costituire la strategia migliore, a condizione che le persone ripetano i tentativi rapidamente e frequentemente e imparino in fretta dai propri insuccessi. I progressi intervenuti nelle tecnologie di simulazione e prototipazione veloce hanno reso molto più facile e molto meno costoso operare in questo modo.

Considerate quello che abbiamo scoperto in uno studio su 391 team che progettavano circuiti integrati su misura per i clienti. I team che seguivano un approccio iterativo ed effettuavano test iniziali e frequenti commettevano più errori lungo il percorso. Ma siccome impiegavano tecnologie di prototipazione a basso costo, facevano meglio (in termini di tempo e di sforzo richiesto) dei team che tentavano di fare centro al primo tentativo. I team che si ritrovavano a sostenere costi più elevati di realizzo del prototipo investivano maggiormente sulla definizione delle specifiche, sullo sviluppo e sulla verifica. E poiché facevano le iterazioni in una fase successiva del processo - e ne facevano molte meno - ritardavano la scoperta di problemi critici.

Sperimentare tante idee diverse è cruciale per i progetti di innovazione. Quando le persone sperimentano rapidamente e frequentemente, molti concetti innovativi si dimostrano ovviamente impraticabili. Ma questi insuccessi iniziali possono essere desiderabili, perché consentono ai team di eliminare rapidamente le opzioni insoddisfacenti e di concentrarsi su alternative più promettenti. Un crash test da cui risulta che un nuovo modello di automobile è insicuro, un nuovo farmaco che si rivela tossico, o un'interfaccia per l'utente che confonde i clienti possono essere tutti risultati desiderabili - sempreché emergano all'inizio del processo, quando sono stati impegnate ancora poche risorse, i progetti sono ancora estremamente flessibili e si possono tentare altre soluzioni.

Un classico esempio dei vantaggi dell'approccio "fallire presto, fallire spesso" è la sorprendente vittoria dell'équipe di New Zealand nell'edizione 1995 dell'America's Cup. Per testare nuove idee finalizzate al miglioramento della chiglia, il team di progettazione ha usato due barche pressoché identiche: una che è stata modificata nel corso del progetto e l'altra, "di controllo", che non è stata modificata. Il team simulava ogni giorno delle ipotesi su una workstation grafica locale, applicava quelle che apparivano promettenti a una barca, la faceva gareggiare con la barca di controllo e analizzava i risultati. Per contro, la squadra concorrente, l'équipe Dennis Conner, che aveva a disposizione dei computer più potenti (i supercomputer della Boeing), effettuava un gran numero di simulazioni ogni tre o quattro settimane e poi testava possibili soluzioni su una barca. Alla fine, New Zealand ha completato molti più cicli di apprendimento, ha eliminato più rapidamente le idee non promettenti e ha finito per sconfiggere la barca di Dennis Conner, Young America.

Dovrebbe essere ormai chiaro che gli esperimenti non coronati da successo non sono necessariamente esperimenti falliti. Generano nuove informazioni che l'innovatore non era in grado di prevedere. Più rapido è il ciclo di sperimentazione, più feedback si può raccogliere e incorporare in nuove sessioni di esperimenti su idee innovative e potenzialmente rischiose. In un ambiente di questo tipo, i dipendenti tendono a perseverare anche nei momenti difficili, a impegnarsi in un lavoro più sfidante e a fare meglio dei loro omologhi che temono il rischio.

Ma creare un ambiente simile non è facile - come ha spiegato Amy C. Edmondson nel suo articolo "Strategie per imparare dagli insuccessi” (HBR aprile 2011). Il fallimento può causare imbarazzo ed evidenziare dei vuoti di conoscenze potenzialmente in grado di minare l'autostima degli individui e la loro immagine all'interno dell'organizzazione. Dopotutto, con quale frequenza i manager vengono promossi e i team vengono premiati per aver denunciato prontamente dei problemi che portano all'eliminazione di un progetto - anche se la tempestiva riallocazione delle risorse va a beneficio dell'azienda? Ciò è particolarmente vero nelle organizzazioni che hanno costruito un ambiente basato sulla "tolleranza zero per l'insuccesso" o su una politica "error-free" (con l'applicazione del metodo Six Sigma).

Thomas Alva Edison aveva capito tutto questo. Organizzò i suoi celebri laboratori intorno al concetto di sperimentazione rapida, posizionando i macchinari per la costruzione dei modelli vicino ai locali dove si conducevano gli esperimenti in modo che gli addetti alle macchine potessero cooperare strettamente con i ricercatori. I laboratori ospitavano biblioteche che contenevano un gran numero di libri, in modo che le informazioni si potessero reperire rapidamente; accanto c'erano dei magazzini estremamente ben forniti; e vi operava una forza lavoro eterogenea, composta da artigiani, ricercatori e ingegneri. Edison voleva essere sicuro che quando lui o i suoi collaboratori avevano un'idea, si potesse trasformare immediatamente in un modello operativo o in un prototipo. «La vera misura del successo è il numero di esperimenti che si possono effettuare in 24 ore», diceva.

I PROGRESSI INTERVENUTI NELL'INFORMATION TECHNOLOGY, come la progettazione, la modellizzazione e la simulazione al computer, hanno già consentito alle aziende di fare grandi passi avanti nello sviluppo di prodotti migliori in tempi più brevi e a un costo più basso. Molte imprese, tuttavia, non hanno sfruttato appieno i potenziali questi strumenti, perché il loro pensiero manageriale non si è evoluto con la stessa rapidità della tecnologia: continuano ad affrontare l'attività di sviluppo dei nuovi prodotti, che genera informazioni altamente variabili, come se fosse analoga alla produzione. Con il continuo progredire dell'IT, l'opportunità di migliorare il processo di sviluppo dei nuovi prodotti diventerà ancora più consistente. Ma diventeranno ancora più consistenti anche i rischi per le aziende restie a convincersi che lo sviluppo dei prodotti è profondamente diverso dalla produzione.

Stefan Thomke è il titolare della cattedra di Business Administration della Harvard Business-School.

Donald Reinertsen é presidente di Reinertsen & Associates, una società di consulenza di Redondo Beach, in California. Il suo ultimo libro è The Principles of Product Development Flow (Celeritas Publishing, 2009).