Volgens onderzoek heersen er zes grote mythes onder managers in productontwikkeling. Het betreft een set van ideeën waarmee men het proces efficiënt wil maken, maar die in werkelijkheid een tegengesteld effect hebben. Nochtans kan het hanteren van enkele eenvoudige richtlijnen voor een aanzienlijke verbetering zorgen.
Voor de meeste managers in de productontwikkeling is het op tijd en binnen budget aanleveren van projecten een continue strijd. Er zijn nooit genoeg middelen en hun oversten verwachten een betrouwbare planning en tastbare resultaten. Daarom pushen ze hun teams om nog zuiniger te zijn, plannen nog gedetailleerder uit te werken en afwijkingen t.o.v. de planning tot het minimum te beperken. Deze benadering kan misschien wel werken om productieafdelingen die onderpresteren aan te pakken, maar kan inspanningen in productontwikkelingen schaden.
De kritieke verschillen tussen productontwikkeling en productie onderschatten is de oorzaak van verschillende foute redeneringen die de planning, uitvoering en evaluatie van productontwikkelingsprojecten ondermijnen. Dit is de conclusie die Stefan Thomke, professor aan de Harvard Business School, en Donald Reinertsen trekken na het onder de loep nemen van meer dan 50 jaar onderzoek ter zake. Op basis van hun onderzoek komen ze tot een zestal mythes die de productontwikkelingsprojecten teisteren. In dit artikel bespreken we de eerste twee mythes. Een volgend artikel in de reeks gaat in op de overige mythes.
Mythe 1: Een hoge bezettingsgraad van de resources zal de performantie verbeteren
Uit hun onderzoek en consultingwerk blijkt dat de grote meerderheid van bedrijven ernaar streven hun productontwikkelaars volledig te belasten met één productontwikkelingsproject. De redenering hierachter is dat projecten langer duren wanneer de betrokkenen geen 100 procent van de tijd aan een project kunnen werken.
In de praktijk gaat deze logica vreemd genoeg niet op: de snelheid van een project, de efficiëntie en de kwaliteit van de output verminderen onvermijdelijk wanneer managers hun productontwikkelaars 100% van de tijd willen bezighouden. Een hoge bezettingsgraad heeft ernstige, negatieve neveneffecten die managers verkeerd inschatten omwille van drie redenen:
- Het effect van een hoge bezettingsgraad op de doorlooptijd wordt sterk onderschat. Heel wat aspecten aan productontwikkeling zijn moeilijk voorspelbaar, terwijl bedrijven het meest bekend zijn met goed voorspelbare repetitieve processen zoals productie- en administratieve processen. Processen zoals productontwikkeling met een grote variatie gedragen zich totaal anders. Bij dergelijke processen zal de doorlooptijd sterk stijgen zodra de werklast toeneemt: 5 procent meer werk kan al zorgen voor een verdubbeling van de doorlooptijd. Dit effect uit de wachtlijntheorie is weinig gekend. Meer nog, de meeste productontwikkelingsteams zijn aanzienlijk overbelast, waardoor om projecten op tijd af te werken soms tot 50 procent meer middelen nodig zijn dan ingepland.
- De economische impact van lange doorlooptijden wordt systematisch onderschat. Een hoge bezettingsgraad van de resources leidt zoals net gesteld onvermijdelijk tot lange doorlooptijden van projecten. Dit maakt het moeilijk voor bedrijven om zich snel aan te passen aan de evoluerende marktbehoeften en snel de zwakheden van hun product te ontdekken.
- In productontwikkeling is de hoeveelheid “work-in-process” grotendeels onzichtbaar. Productiewachtrijen bestaan uit fysieke voorwerpen en wanneer de hoeveelheid work-in-process in een fabriek verdubbelt, is dit duidelijk zichtbaar. Dit is niet het geval in productontwikkeling, waar deze grotendeels bestaat uit informatie, zoals ontwerpdocumentatie, testprocedures en -resultaten en instructies om prototypes te bouwen. Verdubbelt de hoeveelheid work-in-process in een enigineeringproces, dan zijn daar geen fysieke tekenen van. Omdat accountingstandaarden vereisen dat de “R&D-voorraad” aan een waarde van nul wordt begroot, geven financiële resultaten geen indicatie van ernstige buitensporigheden in de work-in-process van productontwikkeling.
Een niet zichtbaar of meetbaar probleem is moeilijk te bestrijden. Een mogelijke oplossing is een capaciteitbuffer voorzien in processen die grote variaties kennen. Enkele vooroplopende bedrijven passen dit al een tijdje toe: al decennia bezet 3M zijn productontwikkelaars op 85 procent van hun capaciteit en Google staat bekend om zijn '20 procent vrije tijd', wat toelaat dat de ingenieurs een dag per week kunnen werken aan wat ze willen, waardoor extra capaciteit beschikbaar is als een project achter op schema raakt. Een dergelijke oplossing vraagt echter moed om te implementeren: weinig organisaties weerstaan de verleiding om elk beetje beschikbare capaciteit in te zetten.
Er zijn echter ook andere haalbare oplossingen :
- Verander de incentives voor het management, bijvoorbeeld door een testafdeling voor snelle resultaten (de tijd gemeten tussen aanvraag en afwerking van de test) te belonen, eerder dan voor het efficiënt gebruik van middelen.
- Verhoog selectief de capaciteit: door extra middelen te stoppen in afdelingen waar de bezettingsgraad van de resources al hoog ligt, kan de wachttijd aanzienlijk verlaagd worden. In testomgevingen waar gebruik gemaakt wordt van computermodelling en simulatie is het verhogen van de capaciteit vaak relatief goedkoop, aangezien dit meestal neerkomt op het aankopen van extra computersystemen en softwarelicenties.
- Beperk het aantal actieve projecten: discipline om een strikte limiet te hanteren voor het aantal projecten in de pipeline, resulteert vaak in een scherpere focus en duidelijkere prioriteiten.
- Maak de hoeveelheid work-in-process beter zichtbaar: dit kan bijvoorbeeld via visuele dashborden. Een goed dashbord toont alle actieve werk en geeft aan in welke staat elk deel van het project zich bevindt. Dit bord dient op een centrale plaats binnen de productontwikkeling opgesteld te worden. Teams kunnen dan dagelijks een korte bespreking houden bij dergelijke borden om de inspanningen te coördineren en het werk in beweging te houden.
Mythe 2: Hoe meer opties we aan een product toevoegen, hoe meer de klanten het zullen waarderen
Productontwikkelingsteams lijken te geloven dat extra opties toevoegen waarde creëert voor klanten en er weghalen de waarde doet dalen. Deze benadering verklaart waarom alledaagse producten, zoals computers, auto's of zelfs afstandsbedieningen, vaak zo complex zijn. Nochtans blinken succesvolle producten eerder uit in elegante eenvoud en gebruiksgemak. Toch vereist deze 'less-is-more'-theorie meer inspanningen, en wel op twee vlakken van productontwikkeling:
- Definieer goed het probleem dat je wil oplossen. Het op te lossen probleem aflijnen is een van de meest onderschatte onderdelen van het innovatieproces, waaraan veel bedrijven veel te weinig tijd aan besteden. Toch is deze fase belangrijk, omdat hierdoor de ontwikkelingsteams een duidelijk begrip krijgen over de doelen. Zich buigen over één centrale vraag, zoals waar het onderscheid ligt met de concurrentie, vraagt de nodige tijd en onderzoek om tot een goed antwoord te komen maar loont de moeite.
- Verberg of laat zaken weg : Ontwikkelaars zijn vaak geneigd indruk te willen maken door briljante technische oplossingen uit te denken die hun peers en management verbazen. Maar vaak verkiezen klanten een product dat moeiteloos werkt boven een gesofisticeerd en complex product. Vanuit het oogpunt van de klant lossen de beste ontwerpen een probleem op een eenvoudige manier op en verbergen ze vaak het werk waarop ontwikkelaars zo fier zijn.
Bepalen welke opties weg te laten is minstens zo belangrijk als uitzoeken welke opgenomen moeten worden. Jammer genoeg voegen heel wat ondernemingen, in een poging innovatief te zijn, elke mogelijke feature toe, zonder de waarde voor de klant of gebruiksgemak, echt te overwegen. Als dan toch een geplande functionaliteit weggelaten wordt, is dit omdat ze kosten moeten besparen, achter op schema geraakt zijn of het ergens fout gelopen is.
In plaats hiervan zouden managers zich moeten focussen op de mate waarin het weglaten van voorgestelde opties het product al dan niet verbetert en het team toelaten zich te concentreren op zaken die de gebruikservaring bij de klant echt verbeteren.
