Zes mythes over productontwikkeling

Artwork: Ricky Allman, Undertable, 2011, acryl op canvas, 72″ x 48″

De meeste productontwikkelingsmanagers hebben altijd moeite om projecten op tijd en binnen budget binnen te halen. Ze hebben nooit genoeg middelen om de klus te klaren, en hun bazen eisen voorspelbare planningen en deliverables. Dus pushen de managers hun teams om zuiniger te zijn, om meer gedetailleerde plannen te schrijven, en om afwijkingen in de planning en verspilling te minimaliseren. Maar deze aanpak, die goed kan werken bij het ombuigen van slecht presterende fabrieken, kan de productontwikkeling juist schaden.

Hoewel veel bedrijven productontwikkeling behandelen alsof het vergelijkbaar is met productie, zijn de twee wezenlijk verschillend. In de wereld van de productie van fysieke objecten zijn de taken repetitief, de activiteiten redelijk voorspelbaar, en de producten die worden gemaakt kunnen zich maar op één plaats tegelijk bevinden. Bij productontwikkeling zijn veel taken uniek, veranderen de projecteisen voortdurend en is de output – mede dankzij het wijdverbreide gebruik van geavanceerde computerondersteunde ontwerpen en simulaties en de integratie van software in fysieke producten – informatie, die zich op meerdere plaatsen tegelijk kan bevinden.

Het niet onderkennen van deze cruciale verschillen heeft geleid tot verschillende denkfouten die de planning, uitvoering en evaluatie van productontwikkelingsprojecten ondermijnen. Samen hebben we meer dan 50 jaar besteed aan het bestuderen en adviseren van bedrijven op het gebied van productontwikkeling, en we zijn deze misvattingen – en andere die om verschillende redenen ontstaan – tegengekomen in een breed scala van industrieën, waaronder halfgeleiders, auto’s, consumentenelektronica, medische apparatuur, software en financiële diensten. In dit artikel leggen we ze bloot en bieden we manieren om de problemen die ze veroorzaken te overwinnen.

Valsheid 1: Een hoge bezettingsgraad van middelen zal de prestaties verbeteren.

In zowel ons onderzoek als ons advieswerk hebben we gezien dat de overgrote meerderheid van bedrijven ernaar streeft om hun productontwikkelingsmiddelen volledig in te zetten. (Een van ons, Donald, heeft door middel van enquêtes in executive cursussen aan het California Institute of Technology ontdekt dat de gemiddelde productontwikkelingsmanager de bezettingsgraad boven de 98% houdt). De logica lijkt voor de hand te liggen: projecten duren langer als mensen niet 100% van de tijd aan het werk zijn – en daarom zal een drukke ontwikkelingsorganisatie sneller en efficiënter zijn dan een die minder goed is in het benutten van haar mensen.

Maar in de praktijk gaat die logica niet op. We hebben gezien dat de snelheid, efficiency en kwaliteit van projecten onvermijdelijk afnemen wanneer managers het werk van hun productontwikkelaars volledig volstoppen, hoe bekwaam die managers ook zijn. Een hoge bezettingsgraad heeft ernstige negatieve neveneffecten, die managers om drie redenen onderschatten:

Zij houden niet ten volle rekening met de intrinsieke variabiliteit van ontwikkelingswerk.

Veel aspecten van productontwikkeling zijn onvoorspelbaar: wanneer projecten zullen aankomen, welke individuele taken ze zullen vereisen, en hoe lang het zal duren voordat werknemers die dergelijke taken nog nooit eerder hebben aangepakt, ze zullen uitvoeren. Bedrijven zijn echter het meest vertrouwd met repetitieve processen zoals productie en transactieverwerking, waar het werk niet veel verandert en verrassingen schaars zijn. Dergelijke processen gedragen zich ordelijk naarmate het gebruik van middelen toeneemt. Voeg 5% meer werk toe, en het zal 5% meer tijd kosten om te voltooien.

Processen met een hoge variabiliteit gedragen zich heel anders. Naarmate de bezetting toeneemt, nemen de vertragingen dramatisch toe. (Zie het voorbeeld “Hoge bezettingsgraad leidt tot vertragingen.”) Voeg 5% meer werk toe, en het kan 100% langer duren om het af te ronden. Maar weinig mensen begrijpen dit effect. Uit onze ervaring met honderden productontwikkelingsteams is gebleken dat de meeste veel te veel werk hebben. Om alle projecten op tijd en binnen budget af te ronden, zouden sommige organisaties minstens 50% meer middelen nodig hebben gehad dan ze hadden.

Het is waar dat een deel van de variabiliteit het gevolg is van een gebrek aan discipline, en dat sommige product-ontwikkelingstaken (zoals het ontwerpen van onderdelen voor een vliegtuigprototype of het uitvoeren van klinische tests) meer repeterend werk omvatten. Maar ook al is een deel van het werk voorspelbaar, als het gecombineerd wordt met ander onvoorspelbaar werk, krijg je te maken met wachtrijproblemen.

Ze begrijpen niet hoe wachtrijen de economische prestaties beïnvloeden.

Een hoge bezetting van middelen leidt onvermijdelijk tot wachtrijen van projecten. Wanneer gedeeltelijk voltooid werk stilligt, wachtend tot er capaciteit beschikbaar komt, zal de duur van het totale project toenemen. Wachtrijen vertragen ook de feedback, waardoor ontwikkelaars langer onproductieve paden volgen. Ze maken het voor bedrijven moeilijk om zich aan te passen aan veranderende marktbehoeften en om zwakke punten in hun product op te sporen voor het te laat is. Ironisch genoeg zijn dit precies de problemen waarvan managers denken dat een hoge bezettingsgraad hun teams in staat zal stellen ze te vermijden.

Zelfs als managers weten dat ze wachtrijen creëren, realiseren ze zich zelden de economische kosten. Hoewel die kosten kunnen worden gekwantificeerd, hebben we gemerkt dat de overgrote meerderheid van de bedrijven ze niet berekent. Managers moeten de kosten van wachtrijen afwegen tegen de kosten van onderbenutte capaciteit om de juiste balans te vinden.

In productontwikkeling is de werk-in-procesvoorraad overwegend onzichtbaar.

Fabricagewachtrijen bestaan uit fysieke dingen, en als de voorraad in een fabriek verdubbelt, is dat duidelijk. Dat is niet het geval bij productontwikkeling, waar de voorraad grotendeels bestaat uit informatie, zoals ontwerpdocumentatie, testprocedures en -resultaten, en instructies voor het bouwen van prototypen. Wanneer de voorraad verdubbelt in een engineeringproces, zijn er geen fysieke tekenen. Bovendien, omdat de boekhoudnormen vereisen dat de meeste R&D voorraden tegen nulwaarde worden geboekt, geven financiële overzichten geen indicatie van ernstige voorraadoverschotten in productontwikkeling.

Het is erg moeilijk om een probleem te bestrijden dat je niet kunt zien of meten. Denk eens aan de situatie bij een groot farmaceutisch bedrijf. Enkele jaren geleden stond het pas benoemde hoofd van de afdeling geneesmiddelenontwikkeling voor een bestuurlijk dilemma. Zoals andere senior executives die grote R&D organisaties leiden, probeerde hij manieren te vinden om zijn wetenschappers innovatiever te maken. Hij wilde dat ze meer zouden experimenteren met nieuwe chemische verbindingen die veelbelovende nieuwe geneesmiddelen zouden kunnen opleveren, en tegelijkertijd dat ze weinigbelovende kandidaten zo snel mogelijk zouden elimineren. Experimenten met levende organismen vielen echter onder de verantwoordelijkheid van dierproeven, een afdeling die niet onder zijn controle stond en werd gerund als een kostenplaats. De afdeling werd geëvalueerd op basis van de efficiëntie waarmee de middelen voor proeven werden gebruikt, wat uiteraard leidde tot een hoge bezettingsgraad. Bijgevolg moesten de wetenschappers die geneesmiddelen ontdekten drie tot vier maanden wachten op de resultaten van tests die iets meer dan een week in beslag namen. De “goed beheerde” testorganisatie belemmerde de vooruitgang van de ontdekkingseenheid.

De voor de hand liggende oplossing voor dergelijke problemen is te zorgen voor een capaciteitsbuffer in processen die sterk variabel zijn. Sommige bedrijven hebben dit al lang begrepen. Al tientallen jaren plant 3M productontwikkelaars op 85% van hun capaciteit. En Google staat bekend om zijn “20% time” (waarbij ingenieurs één dag per week mogen werken aan wat ze maar willen – een praktijk die betekent dat er extra capaciteit beschikbaar is als een project achterloopt op schema). Onze ervaring is echter dat dit soort oplossingen vrij moeilijk te implementeren is. Zoals we zullen bespreken, kunnen maar weinig organisaties de verleiding weerstaan om elk laatste beetje beschikbare capaciteit te gebruiken. Managers beginnen reflexmatig met meer werk wanneer ze ongebruikte tijd zien.

Maar er zijn andere haalbare oplossingen:

Het management-controlesysteem veranderen.

Voor het farmaceutische bedrijf zou dit kunnen inhouden dat er stappen worden ondernomen om de doelstellingen van de proefdiereenheid af te stemmen op die van de ontdekkingseenheid. Het bedrijf zou bijvoorbeeld dierproeven kunnen belonen voor snelle antwoorden (meten van de tijd tussen aanvraag en voltooiing van de test) in plaats van het gebruik van middelen.

Selectief de capaciteit verhogen.

Extra middelen toevoegen aan de gebieden waar de bezettingsgraad 70% of hoger is, kan de wachttijd aanzienlijk verkorten. Als het farmaceutische bedrijf dit bij dierproeven zou doen, zou het veel sneller feedback krijgen over nieuwe chemische verbindingen. In instellingen waar proeven worden uitgevoerd met behulp van computermodellen en -simulaties, is het vergroten van de capaciteit vaak relatief goedkoop, omdat er alleen maar extra computerapparatuur en softwarelicenties hoeven te worden aangeschaft.

Beperk het aantal actieve projecten.

Als het farmaceutische bedrijf de capaciteit van dierproeven niet kan verhogen, kan het de bezettingsgraad nog steeds verlagen door het aantal actieve projecten voor het onderzoeken van nieuwe chemische verbindingen te verminderen. De discipline om een harde grens te stellen aan wat er in een productontwikkelingspijplijn terechtkomt, resulteert vaak in een scherpere focus en duidelijkere prioriteiten.

Maak de werk-in-process inventaris gemakkelijker te zien.

Een methode is het gebruik van visuele controleborden. Deze kunnen verschillende vormen aannemen, maar het belangrijkste is dat een soort fysiek teken, zoals een Post-it briefje, het ontwikkelingswerk weergeeft (zie de tentoonstelling “Typisch werk-in-proces controlebord”). Een controlebord moet al het actieve werk weergeven en laten zien in welke staat elk deel van het project zich bevindt. Het zou in het middelpunt van het managementproces van het team moeten staan. Teams kunnen dagelijks 15 minuten stand-up meetings houden rond dergelijke borden om de inspanningen te coördineren en het werk in beweging te houden.

Fout 2: Verwerking van werk in grote batches verbetert de economie van het ontwikkelingsproces.

Een tweede oorzaak van wachtrijen bij productontwikkeling is de batchgrootte. Laten we zeggen dat een nieuw product uit 200 componenten bestaat. U zou ervoor kunnen kiezen om alle 200 onderdelen te ontwerpen en te bouwen voordat u ze test. Als u in plaats daarvan slechts 20 onderdelen ontwerpt en bouwt voordat u begint met testen, zou de batchgrootte 90% kleiner zijn. Dat zou een ingrijpend effect hebben op de wachtrijtijd, want de gemiddelde wachtrij in een proces is recht evenredig met de partijgrootte.

Het verkleinen van de partijgrootte is een cruciaal principe van lean manufacturing. Kleine partijen stellen fabrikanten in staat het werk in proces te verminderen en de terugkoppeling te versnellen, wat op zijn beurt de cyclustijden, kwaliteit en efficiency verbetert. Kleine batches zijn zelfs nog nuttiger bij productontwikkeling, maar slechts weinig ontwikkelaars beseffen de kracht van deze methode.

Een van de redenen daarvoor is de aard van hun werkstroom. Nogmaals, omdat de informatie die ze produceren meestal onzichtbaar voor hen is, zijn de batchgroottes dat ook. Ten tweede lijken ontwikkelaars een inherente neiging te hebben om grote batches te gebruiken – mogelijk omdat ze ten onrechte denken dat grote batches schaalvoordelen opleveren.

In een goed beheerd proces zal de batchgrootte de transactie- en bewaarkosten in evenwicht brengen (zie de tentoonstelling “Hoe bepaal je de optimale batchgrootte”). Het is vergelijkbaar met het kopen van eieren bij de kruidenier. Als u in één keer een voorraad voor 12 maanden koopt, zijn uw transactiekosten laag, maar de meeste eieren zullen bederven, waardoor uw houderijkosten stijgen. Als u in één keer een voorraad van een dag koopt, is het bederf gering, maar zijn uw transactiekosten hoog. Intuïtief probeer je een evenwicht tussen die twee te vinden.

De bedrijven die begrijpen hoe dit werkt, hebben de IT-ontwikkelingen benut om de partijgrootte te verkleinen, vaak met verbluffende resultaten. Sommige softwarebedrijven die vroeger elke 90 dagen grote partijen code testten, testen nu meerdere malen per dag veel kleinere partijen. Een fabrikant van computerrandapparatuur die een soortgelijke aanpak hanteerde voor zijn softwaregroep, verminderde de cyclustijd voor het testen van software met 95% (van 48 maanden tot 2,5 maanden), verbeterde de efficiëntie met 220% en verminderde het aantal defecten met 33%. De kostenbesparingen waren twee keer zo hoog als het bedrijf had verwacht. Hoewel deze resultaten uitzonderlijk waren, hebben wij vastgesteld dat het verminderen van de batchgrootte de meeste ontwikkelingsprojecten aanzienlijk verbetert. Op dezelfde manier hebben computergestuurde modellerings- en simulatietools de optimale batchgrootte voor experimenten en testen drastisch verlaagd in bedrijven die fysieke producten ontwikkelen.

Valsheid 3: Ons ontwikkelingsplan is geweldig; we hoeven ons er alleen maar aan te houden.

In al ons advieswerk en onderzoek zijn we nog nooit één productontwikkelingsproject tegengekomen waarvan de eisen gedurende het hele ontwerpproces stabiel bleven. Toch hebben veel organisaties een bovenmatig vertrouwen in hun plannen. Ze schrijven afwijkingen toe aan slecht management en slechte uitvoering en, om ze te minimaliseren, volgen ze zorgvuldig elke stap ten opzichte van tussentijdse doelen en mijlpalen. Dergelijk denken is prima voor zeer repetitieve activiteiten in gevestigde productieprocessen. Maar het kan leiden tot slechte resultaten bij productinnovatie, waar dagelijks nieuwe inzichten worden gegenereerd en de omstandigheden voortdurend veranderen.

Een klassieke studie naar het oplossen van technische problemen, uitgevoerd door Thomas Allen van het MIT, benadrukt de veranderlijkheid van ontwikkelingswerk. Hij ontdekte dat ingenieurs die een subsysteem voor de lucht- en ruimtevaart ontwikkelden, een aantal ontwerpalternatieven bedachten en evalueerden voordat zij er een kozen die zij als het beste beschouwden. Onderweg veranderden hun voorkeuren vaak, omdat zij concurrerende technische oplossingen testten en verfijnden. Dit is typisch voor innovatieprojecten: Testen en experimenteren onthullen wat wel en niet werkt, en aanvankelijke veronderstellingen over kosten en waarde kunnen worden weerlegd.

Het definiëren van de behoeften van klanten kan ook moeilijk zijn aan het begin van een product-ontwikkelingsproject. Als je erover nadenkt, is dat niet verwonderlijk: Het is niet eenvoudig voor klanten om nauwkeurig aan te geven wat hun behoeften zijn voor oplossingen die nog niet bestaan. Vertrouwdheid met bestaande productkenmerken kan zelfs een belemmering vormen voor iemands vermogen om zijn of haar behoefte aan een nieuw product kenbaar te maken. De voorkeuren van klanten kunnen ook abrupt veranderen in de loop van een ontwikkelingsproject, als concurrenten nieuwe aanbiedingen introduceren en nieuwe trends opkomen.

Om al deze redenen kan vasthouden aan het oorspronkelijke plan – hoe goed het ook is bedacht en hoe vakkundig het ook is uitgevoerd – een recept zijn voor een ramp. Dit wil niet zeggen dat we niet geloven in planning. Productontwikkeling is een geheel van complexe activiteiten die een zorgvuldige coördinatie en aandacht voor het kleinste detail vereisen. Het plan moet echter worden behandeld als een initiële hypothese die voortdurend wordt herzien naarmate het bewijsmateriaal zich ontvouwt, de economische veronderstellingen veranderen en de opportuniteit opnieuw wordt geëvalueerd. (Zie “The Value Captor’s Process,” door Rita Gunther McGrath en Thomas Keil, HBR mei 2007.)

Fout 4: Hoe eerder het project wordt gestart, hoe eerder het klaar zal zijn.

Zoals we eerder bespraken, is ongebruikte tijd een anathema voor managers. Ze hebben de neiging om elke onderbreking uit te buiten door een nieuw project te starten. Zelfs als de taak niet kan worden voltooid omdat mensen naar een ander project moeten terugkeren, redeneren managers dat alles wat op het nieuwe project wordt gedaan werk is dat later niet meer hoeft te worden gedaan. Een dergelijke denkwijze leidt ertoe dat bedrijven meer projecten starten dan ze krachtig kunnen nastreven, waardoor de middelen verwateren.

Deze verwatering is gevaarlijk. Als een bedrijf aan een project begint voordat het de middelen heeft om door te gaan, zal het langzaam door het ontwikkelingsproces strompelen. Dat is problematisch omdat productontwikkelingswerk zeer vergankelijk is: Veronderstellingen over technologieën en de markt kunnen snel achterhaald zijn. Hoe trager een project vordert, hoe groter de kans dat het moet worden bijgestuurd. Zo ontdekte een militaire afdeling dat de kosten- en termijnoverschrijdingen exponentieel (tot de vierde macht) evenredig waren met de duur van een project. Met andere woorden, wanneer de oorspronkelijke planning van een project verdubbelde, namen de kosten- en planningsoverschrijdingen toe met een factor 16.

Het belang van het verminderen van de hoeveelheid werk in uitvoering wordt duidelijk wanneer we kijken naar een van de klassieke formules van de wachtrijtheorie: De Wet van Little. Deze stelt eenvoudigweg dat de cyclustijd gemiddeld evenredig is met de grootte van de wachtrij gedeeld door de verwerkingssnelheid. Als er dus 20 mensen voor je in de rij staan bij Starbucks en de barista bedient vijf mensen per minuut, dan word je na vier minuten bediend. U kunt de cyclustijd verkorten door de verwerkingssnelheid te verhogen of door het aantal lopende opdrachten te verminderen. In de meeste gevallen is dat laatste de enige praktische keuze.

Bij sommige productontwikkelaars bestaat de oplossing erin de snelheid waarmee zij aan het werk gaan, strikt te beheersen. Zij stemmen het af op het tempo waarin het werk daadwerkelijk wordt voltooid; beheren zorgvuldig het aantal lopende projecten; zorgen ervoor dat een project, zodra het is gestart, voldoende personeel krijgt tot het is voltooid; en weerstaan de verleiding om middelen te stelen uit een lopend project om er nieuwe bij te krijgen.

Fout 5: Hoe meer features we in een product stoppen, hoe leuker klanten het zullen vinden.

Productontwikkelteams lijken te geloven dat het toevoegen van features waarde creëert voor klanten en het onttrekken ervan waarde vernietigt. Deze houding verklaart waarom producten zo ingewikkeld zijn: Afstandsbedieningen lijken onmogelijk te gebruiken, het kost uren om computers in te stellen, auto’s hebben zoveel schakelaars en knoppen dat ze op cockpits van vliegtuigen lijken, en zelfs het bescheiden broodrooster wordt nu geleverd met een handleiding en LCD-displays.

Bedrijven die het geloof dat meer beter is aanvechten, maken producten die elegant zijn in hun eenvoud. Bang & Olufsen, de Deense fabrikant van audioproducten, televisies en telefoons, begrijpt dat klanten niet per se willen rommelen met de equalizer, balans en andere regelaars om de optimale combinatie van instellingen te vinden voor het luisteren naar muziek. De high-end luidsprekers maken automatisch de aanpassingen die nodig zijn om een nummer zo getrouw mogelijk weer te geven. Het enige wat de gebruiker nog hoeft te selecteren is het volume.

Het is moeilijk om bedrijven zover te krijgen dat ze het principe dat minder meer kan zijn, omarmen en toepassen, omdat het extra inspanning vergt op twee gebieden van productontwikkeling:

Het probleem definiëren.

Het probleem formuleren dat ontwikkelaars proberen op te lossen, is het meest onderschatte deel van het innovatieproces. Te veel bedrijven besteden er veel te weinig tijd aan. Maar deze fase is belangrijk omdat het de plaats is waar teams een duidelijk begrip ontwikkelen van wat hun doelen zijn en hypotheses genereren die kunnen worden getest en verfijnd door middel van experimenten. De kwaliteit van een probleemstelling maakt een groot verschil voor het vermogen van een team om zich te concentreren op de paar kenmerken die er echt toe doen.

Toen Walt Disney Disneyland plande, haastte hij zich niet om meer kenmerken (attracties, soorten voedsel, hoeveelheid parkeerruimte) toe te voegen dan andere pretparken hadden. In plaats daarvan, begon hij met het stellen van een veel grotere vraag: Hoe kon Disneyland de bezoekers een magische klantenervaring bezorgen? Het antwoord kwam natuurlijk niet van de ene dag op de andere; het vereiste nauwgezet gedetailleerd onderzoek, constante experimenten, en diepgaande inzichten in wat “magisch” betekende voor Disney en zijn klanten. IDEO en andere bedrijven hebben speciale fasen waarin ze zich volledig onderdompelen in de context waarin het beoogde product of de beoogde dienst zal worden gebruikt. Hun ontwikkelaars lezen alles wat van belang is over de markten, observeren en interviewen toekomstige gebruikers, onderzoeken aanbiedingen die zullen concurreren met het nieuwe product, en synthetiseren alles wat ze hebben geleerd in foto’s, modellen, en diagrammen. Het resultaat is diepgaande inzichten in klanten die worden getest, verbeterd, of verlaten gedurende het iteratieve ontwikkelingsproces.

Bepalen wat te verbergen of weg te laten.

Teams zijn vaak geneigd om te pronken door briljante technische oplossingen te produceren die hun collega’s en het management verbazen. Maar vaak geven klanten de voorkeur aan een product dat gewoon moeiteloos werkt. Vanuit het oogpunt van de klant lossen de beste oplossingen een probleem op de eenvoudigste manier op en verbergen ze het werk waar ontwikkelaars zo trots op zijn.

Een bedrijf dat dit heeft begrepen is Apple. Het staat bekend om veel dingen – innovatieve producten, stijlvolle ontwerpen en slimme marketing – maar zijn grootste kracht is misschien wel zijn vermogen om tot de kern van een probleem door te dringen. (Zie “The Real Leadership Lessons of Steve Jobs,” door Walter Isaacson, in ons aprilnummer.) Zoals wijlen Steve Jobs ooit uitlegde: “Als je naar een probleem begint te kijken en het lijkt heel eenvoudig, begrijp je de complexiteit van het probleem niet echt. En je oplossingen zijn veel te simplistisch. Dan verdiep je je in het probleem, en zie je dat het echt ingewikkeld is. En kom je met al die ingewikkelde oplossingen. Dat is waar de meeste mensen stoppen.” Apple niet. Het blijft maar doorgaan. “Een echt goed persoon blijft doorgaan,” zei Jobs, “en vindt…het belangrijkste onderliggende principe van het probleem en komt met een mooie, elegante oplossing die werkt.”

Bepalen welke functies je weglaat, is net zo belangrijk als – en misschien wel belangrijker dan – uitzoeken welke je opneemt. Helaas gooien veel bedrijven, in een poging om innovatief te zijn, alle mogelijke toeters en bellen erin zonder rekening te houden met belangrijke factoren zoals de waarde voor de klant en het gebruiksgemak. Wanneer dergelijke bedrijven geplande functionaliteit weglaten, is dat meestal omdat ze kosten moeten besparen of omdat ze achterlopen op schema of omdat het team op een andere manier heeft gefaald.

In plaats daarvan moeten managers zich concentreren op de vraag of het schrappen van een voorgestelde functie een bepaald product kan verbeteren en het team in staat kan stellen zich te concentreren op zaken die de algehele klantervaring werkelijk verbeteren. Dit kan worden bepaald door elke vermeende eis te behandelen als een hypothese en deze te testen in kleine, snelle experimenten met potentiële klanten.

Ontwikkelingsteams gaan er vaak van uit dat hun producten klaar zijn als er geen features meer kunnen worden toegevoegd. Misschien zou hun logica andersom moeten zijn: Producten komen dichter bij perfectie als er geen features meer kunnen worden geëlimineerd. Zoals Leonardo da Vinci ooit zei: “Eenvoud is de ultieme verfijning.”

Valsheid 6: We zullen succesvoller zijn als we het in één keer goed doen.

Veel productontwikkelingsprojecten halen hun doelstellingen voor budgetten, schema’s en technische prestaties niet. Ongetwijfeld spelen slechte planning, starre processen en zwak leiderschap allemaal een rol. Maar een andere oorzaak die vaak over het hoofd wordt gezien, is de eis van managers dat hun teams het “in één keer goed doen”. De eis dat het in één keer goed moet zijn, bevoordeelt teams in de richting van de minst riskante oplossingen, zelfs als klanten die niet als een verbetering zien ten opzichte van wat er al beschikbaar is. Om fouten te voorkomen, volgen teams een lineair proces waarin elke fase (specificeren, ontwerpen, bouwen, testen, opschalen, lanceren) zorgvuldig wordt bewaakt door “controlepoorten”. Het werk aan de volgende fase kan pas beginnen als het project door de poort is. Naarmate het project vordert, worden belangrijke verplichtingen aangegaan en nemen de kosten om op nieuwe inzichten te reageren met ordes van grootte toe. Succesvolle tests in latere stadia worden gevierd en verrassingen, hoe waardevol ze ook zijn, worden beschouwd als tegenslagen. Helaas kan zo’n lineaire procesflow leiden tot projectoverschrijdingen, omdat testfeedback wordt vertraagd, teams langer vasthouden aan slechte ideeën dan nodig is, en problemen pas aan het licht komen als het duur is om ze op te lossen.

Een tolerantie voor “het de eerste keer fout hebben” kan de betere strategie zijn, zolang mensen snel en frequent itereren en snel leren van hun mislukkingen. De vooruitgang in simulatie en rapid-prototyping technologieën hebben het werken op deze manier veel gemakkelijker en goedkoper gemaakt.

Bedenk eens wat we hebben gevonden in een onderzoek onder 391 teams die op maat gemaakte geïntegreerde schakelingen ontwierpen. Teams die een iteratieve aanpak volgden en vroegtijdig en frequent tests uitvoerden, maakten onderweg meer fouten. Maar omdat ze gebruik maakten van goedkope prototyping technologieën, presteerden ze beter (in termen van benodigde tijd en inspanning) dan teams die probeerden hun ontwerp in één keer goed te krijgen. De teams die te maken hadden met hoge prototyping kosten, investeerden meer in specificatie, ontwikkeling, en verificatie. En omdat zij hun iteraties later in het proces uitvoerden – en veel minder iteraties uitvoerden – vertraagden zij de ontdekking van kritieke problemen.

Experimenteren met veel verschillende ideeën is cruciaal voor innovatieprojecten. Als mensen snel en vaak experimenteren, zullen veel nieuwe concepten natuurlijk mislukken. Maar zulke vroege mislukkingen kunnen wenselijk zijn, omdat ze teams in staat stellen slechte opties snel te elimineren en zich te richten op veelbelovender alternatieven. Een botsproef die aantoont dat een auto onveilig is, een kandidaat-geneesmiddel dat giftig blijkt te zijn, of een software gebruikersinterface die klanten in verwarring brengt, kunnen allemaal wenselijke uitkomsten zijn – mits ze vroeg in een proces optreden, wanneer nog maar weinig middelen zijn toegezegd, ontwerpen nog zeer flexibel zijn, en andere oplossingen kunnen worden uitgeprobeerd.

Een klassiek voorbeeld van de voordelen van de “misluk vroeg, misluk vaak”-aanpak is de verrassende overwinning van Team Nieuw-Zeeland in de America’s Cup van 1995. Om ideeën voor het verbeteren van het kielontwerp te testen, gebruikte het team twee vrijwel identieke boten: een boot die in de loop van het project werd aangepast en een “controle”-boot die dat niet deed. Dagelijks simuleerde het team hypotheses op een lokaal grafisch werkstation, paste de hypotheses die er veelbelovend uitzagen toe op de ene boot, racete ermee tegen de controleboot, en analyseerde de resultaten. De concurrent, Team Dennis Conner, dat toegang had tot krachtiger computers (supercomputers bij Boeing), voerde daarentegen om de paar weken grote reeksen simulaties uit en testte vervolgens mogelijke oplossingen op één boot. Het resultaat: Team Nieuw-Zeeland voltooide veel meer leercycli, elimineerde veelbelovende ideeën sneller, en versloeg uiteindelijk de boot Young America van Team Dennis Conner.

Wat hopelijk inmiddels duidelijk is, is dat experimenten die uitlopen op mislukkingen niet per definitie mislukte experimenten zijn. Ze leveren nieuwe informatie op die een innovator niet kon voorzien. Hoe sneller de experimenteercyclus, hoe meer feedback kan worden verzameld en verwerkt in nieuwe experimenteerrondes met nieuwe en potentieel riskante ideeën. In een dergelijke omgeving hebben werknemers de neiging om door te zetten wanneer de tijden moeilijk worden, zich in te zetten voor uitdagender werk, en beter te presteren dan hun risicomijdende collega’s.

Maar het creëren van zo’n omgeving is niet eenvoudig – een onderwerp dat Amy C. Edmondson van de Harvard Business School onderzocht in “Strategies for Learning from Failure” (HBR april 2011). Falen kan leiden tot verlegenheid en hiaten in kennis blootleggen, wat het gevoel van eigenwaarde en de status in een organisatie kan ondermijnen. Hoe vaak worden managers immers niet gepromoveerd en teams niet beloond voor het vroegtijdig aan het licht brengen van mislukkingen die ertoe leiden dat een project wordt afgeblazen – ook al komt de vroegtijdige herschikking van kostbare middelen het bedrijf ten goede? Dit is vooral het geval in organisaties die een “nultolerantie voor mislukkingen” of een “foutloze” (Six Sigma) omgeving hebben opgebouwd.

Dit artikel verschijnt ook in: