Six mythes du développement de produits

Artwork : Ricky Allman, Undertable, 2011, acrylique sur toile, 72″ x 48″

La plupart des responsables du développement de produits ont toujours du mal à ramener les projets à temps et à respecter le budget. Ils n’ont jamais assez de ressources pour faire le travail, et leurs patrons exigent des calendriers et des livrables prévisibles. Les responsables poussent donc leurs équipes à être plus parcimonieuses, à rédiger des plans plus détaillés et à minimiser les variations de calendrier et le gaspillage. Mais cette approche, qui peut s’avérer efficace pour redresser des usines peu performantes, peut en fait nuire aux efforts de développement de produits.

Bien que de nombreuses entreprises traitent le développement de produits comme s’il était similaire à la fabrication, les deux sont profondément différents. Dans le monde de la fabrication d’objets physiques, les tâches sont répétitives, les activités sont raisonnablement prévisibles, et les articles créés ne peuvent se trouver qu’à un seul endroit à la fois. Dans le développement de produits, de nombreuses tâches sont uniques, les exigences du projet changent constamment et le résultat – grâce, en partie, à l’utilisation généralisée de la conception et de la simulation assistées par ordinateur avancées et à l’incorporation de logiciels dans les produits physiques – est une information, qui peut résider à plusieurs endroits en même temps.

La non-appréciation de ces différences critiques a donné lieu à plusieurs sophismes qui sapent la planification, l’exécution et l’évaluation des projets de développement de produits. Ensemble, nous avons passé plus de 50 ans à étudier et à conseiller les entreprises sur les efforts de développement de produits, et nous avons rencontré ces idées fausses – ainsi que d’autres qui surgissent pour des raisons différentes – dans un large éventail d’industries, notamment les semi-conducteurs, les automobiles, l’électronique grand public, les appareils médicaux, les logiciels et les services financiers. Dans cet article, nous allons les exposer et proposer des moyens de surmonter les problèmes qu’elles créent.

Attitude 1 : une utilisation élevée des ressources améliorera les performances.

Dans le cadre de nos recherches et de notre travail de conseil, nous avons constaté que la grande majorité des entreprises s’efforcent d’employer pleinement leurs ressources de développement de produits. (L’un d’entre nous, Donald, grâce à des enquêtes menées dans le cadre de cours pour cadres à l’Institut de technologie de Californie, a constaté que le responsable moyen du développement de produits maintient l’utilisation des capacités au-dessus de 98 %). La logique semble évidente : les projets prennent plus de temps lorsque les gens ne travaillent pas 100 % du temps – et par conséquent, une organisation de développement très occupée sera plus rapide et plus efficace qu’une organisation qui n’est pas aussi bonne dans l’utilisation de son personnel.

Mais dans la pratique, cette logique ne tient pas. Nous avons vu que la vitesse, l’efficacité et la qualité de la production des projets diminuent inévitablement lorsque les managers remplissent complètement les assiettes de leurs employés chargés du développement de produits – quelles que soient les compétences de ces managers. Une utilisation élevée a de sérieux effets secondaires négatifs, que les managers sous-estiment pour trois raisons :

Ils ne tiennent pas pleinement compte de la variabilité intrinsèque du travail de développement.

De nombreux aspects du développement de produits sont imprévisibles : quand les projets arriveront, quelles tâches individuelles ils exigeront, et combien de temps il faudra à des travailleurs qui n’ont jamais abordé de telles tâches auparavant pour les réaliser. Les entreprises, en revanche, sont plus familières avec les processus répétitifs tels que la fabrication et le traitement des transactions, où le travail ne change pas beaucoup et où les surprises sont rares. Ces processus se comportent de manière ordonnée lorsque l’utilisation des ressources augmente. Ajoutez 5 % de travail supplémentaire, et il faudra 5 % de temps en plus pour le terminer.

Les processus à forte variabilité se comportent très différemment. Lorsque l’utilisation augmente, les délais s’allongent de façon spectaculaire. (Voir l’exposition  » Une utilisation élevée entraîne des retards « ) Ajoutez 5 % de travail supplémentaire, et le terminer peut prendre 100 % plus de temps. Mais peu de gens comprennent cet effet. Au cours de notre expérience avec des centaines d’équipes de développement de produits, nous avons constaté que la plupart d’entre elles étaient fortement surengagées. Pour mener à bien tous les projets dans le respect des délais et du budget, certaines organisations avec lesquelles nous avons travaillé auraient eu besoin d’au moins 50 % de ressources supplémentaires par rapport à ce qu’elles avaient.

Il est vrai qu’une certaine variabilité est le résultat d’un manque de discipline, et que certaines tâches de développement de produits (comme la conception de composants pour un prototype d’avion ou la réalisation d’essais cliniques) comprennent des travaux plus répétitifs. Mais même si une partie du travail est prévisible, lorsqu’elle est combinée à d’autres travaux imprévisibles, vous verrez apparaître des problèmes de file d’attente.

Ils ne comprennent pas comment les files d’attente affectent la performance économique.

Une utilisation élevée des ressources crée inévitablement des files d’attente de projets. Lorsque des travaux partiellement achevés restent inactifs, en attendant que la capacité se libère, la durée du projet global augmente. Les files d’attente retardent également le retour d’information, ce qui amène les développeurs à suivre des chemins improductifs plus longtemps. Elles empêchent les entreprises de s’adapter à l’évolution des besoins du marché et de détecter les faiblesses de leur produit avant qu’il ne soit trop tard. Ironiquement, ces problèmes sont précisément ceux que les managers pensent qu’une utilisation élevée permettra à leurs équipes d’éviter.

Même lorsque les managers savent qu’ils créent des files d’attente, ils en réalisent rarement le coût économique. Bien que ce coût puisse être quantifié, nous avons constaté que la grande majorité des entreprises ne le calculent pas. Les gestionnaires doivent peser les coûts des files d’attente par rapport aux coûts de la capacité sous-utilisée afin de trouver le bon équilibre.

Dans le développement de produits, les stocks de travaux en cours sont principalement invisibles.

Les files d’attente de fabrication sont constituées de choses physiques, et lorsque les stocks d’une usine doublent, c’est évident. Ce n’est pas le cas dans le développement de produits, où l’inventaire se compose en grande partie d’informations, telles que la documentation de conception, les procédures et les résultats des tests, et les instructions pour la construction de prototypes. Lorsque l’inventaire double dans un processus d’ingénierie, il n’y a pas de signes physiques. De plus, parce que les normes comptables exigent que la plupart des stocks R&D soient comptabilisés à une valeur nulle, les états financiers ne donnent aucune indication de graves excès de stocks dans le développement de produits.

Il est très difficile de combattre un problème que l’on ne peut pas voir ou mesurer. Prenons la situation d’une grande entreprise pharmaceutique. Il y a plusieurs années, son responsable de la découverte de médicaments nouvellement nommé a été confronté à un dilemme managérial. Comme d’autres cadres supérieurs qui dirigent de grandes organisations de R&D, il essayait de trouver des moyens de rendre ses scientifiques plus innovants. Il voulait qu’ils expérimentent davantage de nouveaux composés chimiques susceptibles de générer de nouveaux médicaments prometteurs et, dans le même temps, qu’ils éliminent le plus tôt possible les candidats peu prometteurs. Les expériences sur les organismes vivants relevaient toutefois de la responsabilité des tests sur les animaux, un département qui n’était pas sous son contrôle et qui était géré comme un centre de coûts. Il était évalué en fonction de l’efficacité avec laquelle il utilisait les ressources d’expérimentation, ce qui conduisait naturellement à une utilisation élevée. Par conséquent, les scientifiques chargés de la découverte de médicaments devaient attendre trois à quatre mois pour obtenir les résultats de tests dont la réalisation prenait un peu plus d’une semaine. L’organisation des tests  » bien gérée  » entravait les progrès de l’unité de découverte.

La solution évidente à de tels problèmes consiste à prévoir un tampon de capacité dans les processus qui sont très variables. Certaines entreprises l’ont compris depuis longtemps. Pendant des décennies, 3M a programmé les développeurs de produits à 85% de leur capacité. Et Google est célèbre pour ses « 20% de temps » (permettant aux ingénieurs de travailler un jour par semaine sur ce qu’ils veulent – une pratique qui signifie qu’une capacité supplémentaire est disponible si un projet prend du retard). Cependant, d’après notre expérience, ce type de solution est assez difficile à mettre en œuvre. Comme nous allons le voir, peu d’organisations peuvent résister à la tentation d’utiliser la moindre capacité disponible. Par réflexe, les gestionnaires commencent plus de travail dès qu’ils voient des temps morts.

Mais il existe d’autres solutions viables :

Changer les systèmes de gestion-contrôle.

Pour l’entreprise pharmaceutique, cela pourrait impliquer de prendre des mesures pour aligner les objectifs de l’unité de test sur les animaux avec ceux de l’unité de découverte. L’entreprise pourrait, par exemple, récompenser les tests sur animaux pour la rapidité des réponses (en mesurant le temps entre la demande et la réalisation du test) plutôt que pour l’utilisation des ressources.

Augmenter sélectivement la capacité.

Ajouter des ressources supplémentaires dans les secteurs où les taux d’utilisation sont de 70 % ou plus peut réduire considérablement le temps d’attente. Si l’entreprise pharmaceutique procédait ainsi dans le cadre des tests sur les animaux, elle obtiendrait beaucoup plus rapidement des retours sur les nouveaux composés chimiques. Dans les contextes où les essais sont réalisés à l’aide de modélisation et de simulation informatiques, l’augmentation de la capacité est souvent relativement peu coûteuse, puisqu’il s’agit simplement d’acheter du matériel informatique et des licences logicielles supplémentaires.

Limiter le nombre de projets actifs.

Si la firme pharmaceutique ne pouvait pas augmenter la capacité de l’expérimentation animale, elle pouvait encore abaisser le taux d’utilisation en réduisant le nombre de projets actifs explorant de nouveaux composés chimiques. La discipline consistant à mettre une limite stricte à ce qui entre dans un pipeline de développement de produits permet souvent de se concentrer davantage et de définir des priorités plus claires.

Rendre l’inventaire des travaux en cours plus facile à voir.

Une méthode consiste à utiliser des tableaux de contrôle visuel. Ceux-ci peuvent prendre plusieurs formes, mais l’essentiel est qu’une sorte de jeton physique, tel qu’un post-it, représente les travaux de développement (voir la pièce  » Tableau de contrôle typique des travaux en cours « ). Un tableau de contrôle doit afficher tous les travaux en cours et montrer dans quel état se trouve chaque partie du projet. Il doit être au centre du processus de gestion de l’équipe. Les équipes peuvent organiser des réunions quotidiennes de 15 minutes autour de tels tableaux pour coordonner les efforts et faire avancer le travail.

Attitude 2 : le traitement du travail en grands lots améliore l’économie du processus de développement.

Une deuxième cause de files d’attente dans le développement de produits est la taille des lots. Disons qu’un nouveau produit est composé de 200 composants. Vous pourriez choisir de concevoir et de construire les 200 pièces avant d’en tester une seule. Si, au contraire, vous conceviez et construisiez seulement 20 composants avant de commencer les tests, la taille du lot serait réduite de 90 %. Cela aurait un effet profond sur le temps d’attente, car la file d’attente moyenne dans un processus est directement proportionnelle à la taille du lot.

La réduction de la taille des lots est un principe essentiel de la production allégée. Les petits lots permettent aux fabricants de réduire les travaux en cours et d’accélérer la rétroaction, ce qui, à son tour, améliore les temps de cycle, la qualité et l’efficacité. Les petits lots ont une utilité encore plus grande dans le développement de produits, mais peu de développeurs réalisent la puissance de cette méthode.

Une des raisons est la nature de leur flux de travail. Encore une fois, parce que l’information qu’ils produisent est le plus souvent invisible pour eux, les tailles de lots le sont aussi. Deuxièmement, les développeurs semblent avoir un biais inhérent à l’utilisation de grands lots – peut-être parce qu’ils croient à tort que les grands lots produisent des économies d’échelle.

Dans un processus bien géré, la taille des lots équilibrera les coûts de transaction et de détention (voir l’exposition « Comment déterminer la taille optimale des lots »). C’est similaire à l’achat d’œufs à l’épicerie. Si vous achetez un lot de 12 mois en une seule fois, votre coût de transaction est faible, mais la plupart des œufs se gâteront, ce qui augmentera votre coût de possession. Si vous achetez un approvisionnement d’un jour à la fois, le gaspillage sera faible, mais vos coûts de transaction seront élevés. Intuitivement, vous essayez de trouver un équilibre entre les deux.

Les entreprises qui comprennent comment cela fonctionne ont exploité les progrès de l’informatique pour réduire la taille des lots, souvent avec des résultats étonnants. Certaines entreprises de logiciels qui avaient l’habitude de tester de grands lots de code tous les 90 jours testent désormais des lots beaucoup plus petits plusieurs fois par jour. Un fabricant de périphériques d’ordinateurs qui a utilisé une approche similaire avec son groupe de logiciels a réduit la durée du cycle de test des logiciels de 95 % (de 48 mois à 2,5 mois), amélioré l’efficacité de 220 % et diminué les défauts de 33 %. Les économies réalisées ont été deux fois plus importantes que ce que l’entreprise avait prévu. Bien que ces résultats aient été exceptionnels, nous avons constaté que la réduction de la taille des lots améliore considérablement la plupart des projets de développement. De même, les outils de modélisation et de simulation informatisés ont considérablement réduit la taille optimale des lots d’expérimentation et d’essai dans les entreprises qui développent des produits physiques.

Faux raisonnement 3 : Notre plan de développement est génial ; nous devons juste nous y tenir.

Dans tout notre travail de conseil et de recherche, nous n’avons jamais rencontré un seul projet de développement de produit dont les exigences sont restées stables tout au long du processus de conception. Pourtant, de nombreuses organisations accordent une confiance démesurée à leurs plans. Elles attribuent tout écart à une gestion et une exécution médiocres et, pour les minimiser, elles suivent attentivement chaque étape par rapport aux objectifs intermédiaires et aux jalons. Cette façon de penser convient aux activités hautement répétitives des processus de fabrication établis. Mais il peut conduire à de mauvais résultats dans l’innovation de produits, où de nouvelles idées sont générées quotidiennement et où les conditions changent constamment.

Une étude classique de la résolution de problèmes techniques réalisée par Thomas Allen du MIT met en évidence la nature fluide du travail de développement. Il a constaté que les ingénieurs qui développaient un sous-système aérospatial concevaient et évaluaient un certain nombre d’alternatives de conception avant de choisir celle qu’ils jugeaient la meilleure. En cours de route, leurs préférences changeaient fréquemment, à mesure qu’ils testaient et affinaient les solutions techniques concurrentes. Ce processus est typique des projets d’innovation : Les tests et l’expérimentation révèlent ce qui fonctionne et ce qui ne fonctionne pas, et les hypothèses initiales sur les coûts et la valeur peuvent être réfutées.

Définir les besoins des clients peut également être difficile à faire au début d’un projet de développement de produit. Quand on y pense, ce n’est pas surprenant : Il n’est pas facile pour les clients de spécifier avec précision leurs besoins pour des solutions qui n’existent pas encore. En fait, la familiarité avec les attributs d’un produit existant peut entraver la capacité d’un individu à exprimer son besoin d’un nouveau produit. Les préférences des clients peuvent également changer brusquement au cours d’un projet de développement, à mesure que les concurrents introduisent de nouvelles offres et que de nouvelles tendances émergent.

Pour toutes ces raisons, s’en tenir au plan initial – quelle que soit l’excellence de sa conception et l’habileté de son exécution – peut être une recette pour le désastre. Cela ne veut pas dire que nous ne croyons pas à la planification. Le développement de produits est un ensemble d’activités complexes qui nécessitent une coordination minutieuse et une attention au moindre détail. Cependant, le plan doit être traité comme une hypothèse initiale qui est constamment révisée au fur et à mesure que les preuves s’accumulent, que les hypothèses économiques changent et que l’opportunité est réévaluée. (Voir  » The Value Captor’s Process « , par Rita Gunther McGrath et Thomas Keil, HBR mai 2007.)

Attitude 4 : Plus tôt le projet est lancé, plus tôt il sera terminé.

Comme nous l’avons évoqué précédemment, les temps morts sont l’anathème des managers. Ils ont tendance à exploiter tout temps mort en lançant un nouveau projet. Même si la tâche ne peut pas être achevée parce que les gens doivent retourner sur un autre projet, les gestionnaires raisonnent que tout ce qui est accompli sur le nouveau projet est un travail qui n’aura pas à être fait plus tard. Un tel raisonnement conduit les entreprises à lancer plus de projets qu’elles ne peuvent en poursuivre vigoureusement, ce qui dilue les ressources.

Cette dilution est dangereuse. Si une entreprise se lance dans un projet avant d’avoir les ressources nécessaires pour avancer, elle trébuchera lentement dans le processus de développement. C’est problématique car le travail de développement de produits est hautement périssable : Les hypothèses sur les technologies et le marché peuvent rapidement devenir obsolètes. Plus un projet progresse lentement, plus il y a de chances qu’il doive être réorienté. En effet, une branche de l’armée a découvert que ses dépassements de coûts et de délais étaient exponentiellement proportionnels (à la quatrième puissance) à la durée d’un projet. En d’autres termes, lorsque le calendrier initial d’un projet doublait, les dépassements de coûts et de calendrier augmentaient d’un facteur 16.

L’importance de réduire la quantité de travail en cours est évidente lorsque nous examinons l’une des formules classiques de la théorie des files d’attente : La loi de Little. Elle stipule simplement qu’en moyenne, le temps de cycle est proportionnel à la taille de la file d’attente divisée par le taux de traitement. Ainsi, si 20 personnes font la queue devant vous au Starbucks et que le serveur sert cinq personnes par minute, vous serez servi en quatre minutes. Vous pouvez raccourcir la durée du cycle en augmentant le taux de traitement ou en réduisant le nombre de tâches en cours. Dans la plupart des contextes, cette dernière solution est le seul choix pratique.


Pour certains développeurs de produits, la solution a été de contrôler rigoureusement le rythme auquel ils commencent à travailler. Ils le font correspondre au rythme auquel le travail est effectivement achevé ; ils gèrent soigneusement le nombre de projets en cours ; ils s’assurent qu’une fois qu’un projet est lancé, il est doté d’un personnel adéquat jusqu’à son achèvement ; et ils résistent à la tentation de voler des ressources à un projet en cours pour en intégrer de nouvelles.

Faux raisonnement 5 : Plus nous mettons de fonctionnalités dans un produit, plus les clients l’aimeront.

Les équipes de développement de produits semblent croire qu’ajouter des fonctionnalités crée de la valeur pour les clients et que les soustraire en détruit. Cette attitude explique pourquoi les produits sont si compliqués : Les télécommandes semblent impossibles à utiliser, les ordinateurs prennent des heures à configurer, les voitures ont tellement de commutateurs et de boutons qu’elles ressemblent à des cockpits d’avion, et même l’humble grille-pain est maintenant livré avec un manuel et des écrans LCD.

Les entreprises qui défient la croyance selon laquelle plus est mieux créent des produits élégants dans leur simplicité. Bang & Olufsen, le fabricant danois de produits audio, de téléviseurs et de téléphones, comprend que les clients n’ont pas forcément envie de tripoter l’égaliseur, la balance et autres commandes pour trouver la combinaison optimale de réglages pour écouter de la musique. Ses haut-parleurs haut de gamme effectuent automatiquement les ajustements nécessaires pour reproduire une chanson avec autant de fidélité que possible à l’original. Il ne reste plus aux utilisateurs qu’à sélectionner le volume.

Pour que les entreprises adhèrent et mettent en œuvre le principe selon lequel moins peut être plus, c’est difficile car cela nécessite des efforts supplémentaires dans deux domaines du développement de produits :

Définir le problème.

Articuler le problème que les développeurs vont tenter de résoudre est la partie la plus sous-estimée du processus d’innovation. Trop d’entreprises y consacrent beaucoup trop peu de temps. Pourtant, cette phase est importante car c’est là que les équipes développent une compréhension claire de leurs objectifs et génèrent des hypothèses qui peuvent être testées et affinées par des expériences. La qualité d’un énoncé de problème fait toute la différence dans la capacité d’une équipe à se concentrer sur les quelques fonctionnalités qui comptent vraiment.

Lorsque Walt Disney a planifié Disneyland, il ne s’est pas précipité pour ajouter plus de fonctionnalités (manèges, types de nourriture, quantité de parking) que ce que les autres parcs d’attractions avaient. Au contraire, il a commencé par poser une question beaucoup plus vaste : Comment Disneyland pourrait-il offrir aux visiteurs une expérience client magique ? La réponse n’est certainement pas venue du jour au lendemain ; elle a nécessité des recherches minutieuses, une expérimentation constante et une compréhension approfondie de ce que le mot « magique » signifie pour Disney et ses clients. IDEO et d’autres entreprises ont des phases dédiées au cours desquelles ils s’immergent complètement dans le contexte dans lequel le produit ou le service envisagé sera utilisé. Leurs développeurs lisent tout ce qui est intéressant sur les marchés, observent et interrogent les futurs utilisateurs, recherchent les offres qui concurrenceront le nouveau produit et synthétisent tout ce qu’ils ont appris en images, modèles et diagrammes. Il en résulte des connaissances approfondies sur les clients qui sont testées, améliorées ou abandonnées tout au long du processus de développement itératif.

Déterminer ce qu’il faut cacher ou omettre.

Les équipes sont souvent tentées de frimer en produisant des solutions techniques brillantes qui émerveillent leurs pairs et la direction. Mais souvent, les clients préfèrent un produit qui fonctionne simplement sans effort. Du point de vue du client, les meilleures solutions résolvent un problème de la manière la plus simple et cachent le travail dont les développeurs sont si fiers.

Une entreprise qui a compris cela est Apple. Elle est connue pour de nombreuses choses – des produits innovants, des designs élégants et un marketing avisé – mais sa plus grande force est peut-être sa capacité à aller au cœur d’un problème. (Voir « Les véritables leçons de leadership de Steve Jobs », par Walter Isaacson, dans notre numéro d’avril). Comme l’a expliqué le regretté Steve Jobs, « Lorsque vous commencez à examiner un problème et qu’il semble vraiment simple, vous ne comprenez pas vraiment la complexité du problème. Et vos solutions sont beaucoup trop simplifiées. Puis vous vous attaquez au problème, et vous voyez qu’il est vraiment compliqué. Et vous trouvez toutes ces solutions alambiquées….. C’est là que la plupart des gens s’arrêtent. » Pas Apple. Elle continue à travailler. « La personne vraiment géniale va continuer à avancer », a déclaré Jobs, « et trouver… le principe clé sous-jacent du problème et proposer une solution belle et élégante qui fonctionne. »

Déterminer les fonctionnalités à omettre est tout aussi important que – et peut-être plus important que – déterminer celles à inclure. Malheureusement, de nombreuses entreprises, dans un effort d’innovation, jettent toutes les cloches et tous les sifflets possibles sans tenir pleinement compte de facteurs importants tels que la valeur pour les clients et la facilité d’utilisation. Lorsque ces entreprises omettent certaines fonctionnalités prévues, c’est généralement parce qu’elles doivent réduire les coûts, qu’elles ont pris du retard ou que l’équipe a échoué d’une autre manière.

Au contraire, les responsables devraient s’attacher à déterminer si la suppression d’une fonctionnalité proposée pourrait améliorer un produit particulier et permettre à l’équipe de se concentrer sur les choses qui améliorent vraiment l’expérience globale du client. Cela peut être déterminé en traitant chaque exigence présumée comme une hypothèse et en la testant dans de petites expériences rapides avec des clients potentiels.

Les équipes de développement partent souvent du principe que leurs produits sont terminés lorsqu’il n’est plus possible d’ajouter des fonctionnalités. Leur logique devrait peut-être être l’inverse : Les produits se rapprochent de la perfection lorsque plus aucune fonctionnalité ne peut être éliminée. Comme l’a dit un jour Léonard de Vinci, « La simplicité est la sophistication ultime. »

Attitude 6 : Nous aurons plus de succès si nous réussissons du premier coup.

De nombreux projets de développement de produits ne parviennent pas à atteindre leurs objectifs en matière de budget, de calendrier et de performance technique. Sans aucun doute, une mauvaise planification, des processus rigides et un leadership faible jouent tous un rôle. Mais une autre cause souvent négligée est l’exigence des managers que leurs équipes « fassent bien les choses du premier coup ». Le fait d’exiger le succès du premier coup pousse les équipes à opter pour les solutions les moins risquées, même si les clients ne les considèrent pas comme une grande amélioration par rapport à ce qui est déjà disponible. Pire encore, les équipes sont peu incitées à rechercher des solutions innovantes aux problèmes des clients.

Pour éviter de faire des erreurs, les équipes suivent un processus linéaire dans lequel chaque étape (spécifier, concevoir, construire, tester, mettre à l’échelle, lancer) est soigneusement surveillée à des « portes » d’examen. Le travail sur l’étape suivante ne peut pas commencer avant que le projet ne passe par la porte. Au fur et à mesure que le projet avance dans le processus, des engagements importants sont pris et le coût de la réaction à de nouvelles idées augmente de plusieurs ordres de grandeur. Les tests réussis aux derniers stades sont célébrés et les surprises, quelle que soit leur valeur, sont considérées comme des échecs. Malheureusement, un tel flux de processus linéaire peut entraîner des dépassements de projet parce que le retour d’information sur les tests est retardé, que les équipes s’accrochent aux mauvaises idées plus longtemps qu’elles ne le devraient et que les problèmes ne sont déterrés que lorsqu’il est coûteux de les résoudre.

Une tolérance pour « se tromper du premier coup » peut être la meilleure stratégie tant que les gens itèrent rapidement et fréquemment et apprennent rapidement de leurs échecs. Les progrès des technologies de simulation et de prototypage rapide ont rendu ce mode de fonctionnement largement plus facile et moins coûteux.

Considérez ce que nous avons trouvé dans une étude de 391 équipes qui ont conçu des circuits intégrés personnalisés. Les équipes qui ont suivi une approche itérative et effectué des tests précoces et fréquents ont commis plus d’erreurs en cours de route. Mais parce qu’elles ont utilisé des technologies de prototypage peu coûteuses, elles ont obtenu de meilleurs résultats (en termes de temps et d’efforts requis) que les équipes qui ont essayé de réussir leur conception du premier coup. Les équipes qui ont dû faire face à des coûts de prototypage élevés ont investi davantage d’efforts dans la spécification, le développement et la vérification. Et parce qu’elles ont fait leurs itérations plus tard dans le processus – et en ont fait beaucoup moins – elles ont retardé la découverte de problèmes critiques.

L’expérimentation de nombreuses idées diverses est cruciale pour les projets d’innovation. Lorsque les gens expérimentent rapidement et fréquemment, de nombreux concepts novateurs échoueront, bien sûr. Mais ces échecs précoces peuvent être souhaitables car ils permettent aux équipes d’éliminer rapidement les mauvaises options et de se concentrer sur des alternatives plus prometteuses. Un crash test qui montre qu’une conception de voiture n’est pas sûre, un candidat médicament qui s’avère toxique ou une interface utilisateur de logiciel qui déroute les clients peuvent tous être des résultats souhaitables – à condition qu’ils se produisent tôt dans un processus, lorsque peu de ressources ont été engagées, que les conceptions sont encore très flexibles et que d’autres solutions peuvent être essayées.

Un exemple classique des avantages de l’approche  » échouer tôt, échouer souvent  » est la victoire surprenante de l’équipe de Nouvelle-Zélande dans la Coupe de l’America de 1995. Pour tester des idées d’amélioration de la conception de la quille, l’équipe a utilisé deux bateaux presque identiques : un bateau qui a été modifié au cours du projet et un bateau  » témoin  » qui ne l’a pas été. Chaque jour, l’équipe a simulé des hypothèses sur un poste de travail graphique local, a appliqué celles qui semblaient prometteuses à l’un des bateaux, l’a fait courir contre le bateau témoin et a analysé les résultats. En revanche, son concurrent, l’équipe Dennis Conner, qui avait accès à des ordinateurs plus puissants (les superordinateurs de Boeing), effectuait de grandes séries de simulations toutes les quelques semaines, puis testait les solutions possibles sur un seul bateau. Le résultat : L’équipe de Nouvelle-Zélande a réalisé beaucoup plus de cycles d’apprentissage, a éliminé plus rapidement les idées peu prometteuses et a fini par battre le bateau de l’équipe Dennis Conner, Young America.

Ce qui, nous l’espérons, devient clair maintenant, c’est que les expériences qui se soldent par des échecs ne sont pas nécessairement des expériences ratées. Elles génèrent de nouvelles informations qu’un innovateur n’était pas en mesure de prévoir. Plus le cycle d’expérimentation est rapide, plus le retour d’information peut être recueilli et intégré dans de nouvelles séries d’expériences avec des idées nouvelles et potentiellement risquées. Dans un tel environnement, les employés ont tendance à persévérer lorsque les temps sont durs, à s’engager dans des tâches plus stimulantes et à obtenir de meilleurs résultats que leurs pairs peu enclins à prendre des risques.

Mais créer ce type d’environnement n’est pas facile – un sujet qu’Amy C. Edmondson, de la Harvard Business School, a exploré dans  » Strategies for Learning from Failure  » (HBR avril 2011). L’échec peut être source d’embarras et révéler des lacunes dans les connaissances, ce qui peut nuire à l’estime de soi et à la position des individus dans l’organisation. Après tout, combien de fois les managers sont-ils promus et les équipes récompensées pour la révélation précoce d’échecs qui conduisent à l’abandon d’un projet – même si le redéploiement précoce de ressources précieuses profite à l’entreprise ? Cela est particulièrement vrai dans les organisations qui ont construit un environnement « tolérance zéro pour l’échec » ou « sans erreur » (Six Sigma).

Cet article est également publié dans :