1996 degraaf - assessing product development visualizing process and technology with race

7/29/2019 1996 DeGraaf - Assessing Product Development Visualizing Process and Technology With RACE

1/259

I

Robert de Graaf

R.deGraaf

Assessing Product Development

Visualizing Process and Technology

Performance with RACE

AssessingProduc

tDevelopment:

VisualizingProce

ssandTechnologyPerformancewithRACE

ISBN 90-386-0235-9


2/259

STELLINGEN

behorende bij het proefschrift

Assessing Product Development:

Visualizing Process and Technology Performance withRACE

van

Robert de Graaf


3/259

IRACE is een verantwoorde methode om wezenlijke verbetering

van productontwikkeling in gang te zetten.(zie stelling II)

IIHet verbeteren van productontwikkelprocessen lijkt op een

Sisyphus-arbeid: steeds als men denkt dat de top van de berg isbereikt, staat men slechts aan de voet van de volgende -- nog

hogere -- berg.(dit proefschrift, hoofdstuk 5)

IIIPages enqute onder Amerikaanse bedrijven geeft een vertekendbeeld van de problemen die zich tijdens de productontwikkelingvoordoen; Page heeft namelijk managers genquteerd, in plaatsvan teamleden die werkelijk inzicht hebben in de problematiek.

(Page, 1993; dit proefschrift, hoofdstuk 6 en 7)

IVDe basisgedachte achter RACE is het koppelen van de

verbeterinitiatieven van de teamleden aan de verbeterrichtingenvan het management, waardoor de verbetering wordt

gekanaliseerd in een voor het bedrijf geschikte richting.(dit proefschrift hoofdstuk 4)

VHet verkorten van de doorlooptijd en het verhogen van de

productkwaliteit blijken niet de belangrijkste drijfveren voorverbetering van de productontwikkeling te zijn bij bedrijven die

complexe producten produceren, want in 9 van de 10 gevallen isdit namelijk het reduceren van levenscycluskosten -- kostprijs,

productiekosten, servicekosten, recyclingkosten, etcetera.(dit proefschrift, hoofdstuk 4 en 5)


4/259

VIBeter communiceren is niet het belangrijkste goed gedurende

productontwikkeling, want communicatie alleen is onvoldoende;beter samenwerken tussen verschillende disciplines -- zowel in de

techniek als in de levenscyclus -- is de sleutel tot succes.(dit proefschrift, hoofdstuk 7)

VIISamenwerking met leveranciers gedurende de

productontwikkeling moet vanwege stelling V en VI naderwetenschappelijk worden onderzocht.

(dit proefschrift, hoofdstuk 7)

VIIIDe mogelijkheden van de digitale snelweg, zoals informatieoveral ter wereld beschikbaar stellen en zo 24 uur per dag

producten ontwikkelen, zijn eerder een bedreiging dan een kansvoor traditionele productontwikkelorganisaties; het belang vandeze mogelijkheden wordt namelijk noch door managers nochdoor teamleden onderkend met als consequentie dat radicale

verbeterinitiatieven niet kunnen worden aangegrepen.

IXVerbeteren om te verbeteren is de doodsteek voor continue

verbetering.

XBinnen disciplines zoals werktuigbouwkunde, elektrotechniek eninformatica, is te weinig aandacht voor bedrijfskundige aspecten

van productontwikkeling.


5/259

XIAls de praktijk het principile onderzoeksveld is en de

onderzoeker zelf praktijkgericht, is de weg van methodologischeverantwoording lang en ongeplaveid.

XIIPromovendi die lang over hun studie hebben gedaan om sociale

vaardigheden op te doen, kunnen sneller promoveren danpromovendi die dergelijke vaardigheden tijdens hun onderzoek

moeten opdoen.

XIII

Het reizen per trein is vooral leuk als je vanuit je laptop opkijkt enziet dat je met 130 km/u langs een file stuift.

XIVHet schrijven van een proefschrift is als het lezen van een

enerverend boek gedurende een lange treinreis: als het boek uit isblijkt het landschap totaal veranderd.

XV

Beter goed gestolen dan slecht ontwikkeld (met dank aan CERC).-- ook deze stelling is goed gestolen --

XVIDe wachtgeldproblematiek met betrekking tot AiOs kan wordenopgelost door het wachtgeld in te houden op het salaris van de

verantwoordelijke hoogleraar, zodat deze voldoendeprojectmanagementvaardigheden zal ontwikkelen om de AiO

tijdig te laten promoveren.


6/259


7/259

Omslagontwerp: Delmar Molenaar

Druk: Verweij, Mijdrecht

1996, R. de Graaf

Alle rechten voorbehouden. Uit deze uitgave mag niets worden gereproduceerd doormiddel van boekdruk, fotokopie, microfilm of welk ander medium dan ook, zonderschriftelijke toestemming van de auteur.

All rights reserved. No part of this publication may be reproduced, stored in a retrievalsystem, or transmitted in any form by any means, mechanical, photocopying, recording orotherwise, without the written permission of the author.


8/259

Assessing Product Development:Visualizing Process and Technology Performance with RACE

PROEFSCHRIFT

ter verkrijging van de graad van doctor aan deTechnische Universiteit Eindhoven, op gezag van de

Rector Magnificus, prof.dr. M. Rem, voor eencommissie aangewezen door het College van

Dekanen in het openbaar te verdedigenop maandag 9 september 1996 om 16.00 uur

door

Robert de Graaf

geboren te Emmen


9/259

Dit proefschrift is goedgekeurd door de promotoren:

prof.dr.ir. E.J. Sol

enprof.ir. P.W. Sanders

Copromotor:

dr.ir. H.J. Pels


10/259


11/259

I

PREFACE

My dissertation presents the development and practical application of anassessment method for Product Development. This assessment method--theReadiness Assessment for Concurrent Engineering (RACE)--assists ProductDevelopment management in defining improvement goals for ProductDevelopment practices, and guides the generation suitable improvementinitiatives by Product Development team members.

RACE is originally developed by the Concurrent Engineering ResearchCenter (CERC) at West Virginia University (Morgantown, WV, USA). RACEhas been enhanced to suit the needs of European companies. Based on theapplication results of the assessment, an additional step for the RACEProcedure and two additional parts for the RACE Model have beenconstructed. Furthermore, the deployment of the results of RACE is studied,which indicates that the assessed companies need guidance after RACE tosuccessfully change their Product Development practices.

The research for this dissertation is accomplished in close cooperation withCERC, where I received basic training in the assessment model andprocedure. Especially Dr. Harsh Karandikar (now with SAIC; McLean, VA,USA), and CERCs director Prof. Ramana Reddy have provided substantialtime and effort for this study. The cooperation with CERC was establishedby Eric van de Linde of the Royal Dutch Embassy in the USA. The travelexpenses for the cooperation with CERC were partly funded by a grant

from the VSB Fonds foundation (Utrecht, The Netherlands).I have been able to present parts of my research during the ConcurrentEngineering conferences in 1994 (CE94; Pittsburgh, PA, USA) and 1995(CE95; McLean, VA, USA); the conferences of the International Society ofProduct Innovation Management in 1993 (ISPIM 93; Eindhoven, TheNetherlands) and 1995 (ISPIM 95; Rome, Italy), and the IEEE ElectronicDesign Workshop in 1995 (Breckenridge, CO, USA). The travel expenses forthese conferences are partly covered by grants from Shell Netherlands andthe Dutch National Science Foundation, NWO. The manuscripts createdduring my Ph.D. work have been published in the proceeding of CE94,

CE95, ISPIM 93, ISPIM 95, and Computers in Industry. Two manuscriptshave been accepted for publication, in Concurrent Engineering: Researchand Applications, and for the CE96 conference (Toronto, Canada).Currently, one manuscript is under review for publication in the Journal ofEngineering and Technology Management.

The work presented in this dissertation depended heavily on thecooperation of Product Development organizations in the Netherlands,


12/259

Summary in Dutch

II

Belgium, England and the USA. Unfortunately, due to the non disclosureagreements, I cannot thank these organizations and more importantly thepeople in these organizations in person. Furthermore, I would like to thankthe participants of the Dommelgroep for their comments on my work. There

is one organization I can name: Berenschot (Utrecht, The Netherlands). Iappreciate their attention for my work and especially enjoyed collaboratingwith Frank van Dam and Gert ten Cate.

Many people have stimulated me in producing this dissertation. Manyfriends and family members inquired about my progress. Especially mygirlfriend Natascha and my parents have played an important role.Natascha provided lots of input and feedback for my dissertation, especiallyfor Chapters 1, 2 and 6. This was excellent feedback, even though she wasnot familiar with the field of research. Furthermore, she helped me throughthe obvious dips in motivation, even though she did not get the attentionshe deserved. My parents enabled me to explore the USA for my researchand provided mental back up as well. My father even proofread thecomplete concept version of this dissertation. Without the help of Nataschaand my parents, this dissertation would have been much less distinctive.

At the Eindhoven University of Technology, Faculty of TechnologyManagement, I have a number of people to thank as well. My advisor, Prof.Egbert Jan Sol, managed to provide as much time as needed, even thoughhe is only a part-time professor. His support went far beyond progressmonitoring, as we have executed the first four assessments jointly, andspent a week at CERC to outline the improvement selection matrix. My co-advisor Dr. Henk Jan Pels provided the backbone for my research as he was

always available for monitoring my research project. He brought fresh ideasfor further enhancement of my research by putting it into context, andillustrated enthusiasm for my work from day one. Prof. Piet Sanders, mysecond advisor, made sure I could start this work and gave detailed feedback on the generated documents. Prof. Hans Wortmann provided me withsome extra income through my work for him as Editorial Office Managerfor Computers in Industry. More importantly, he nearly always managed tofind time to comment my intermediate research results, even though hisagenda was already completely filled.

Additionally, Jaap de Koning was a capable sparring partner in the start up

phase of my research, by forcing me to narrow down the field of myresearch. Dr. Freek Erens showed much interest in my work and eveninvited me to write a joint future work section in his dissertation. Finally,Luuk Kornelius was a not only vivacious part-time university room mate,but a welcome peer in the turbulent assessment of Case 11 as well. Besides,he joined me in the write up of the subsequent article on inter-organizational Concurrent Engineering.


13/259

Samenvatting

III

My colleagues in the Manufacturing Technology group all provided usefulinput during my presentations. Additionally, Dr. Ad de Ron provided themeans for all my uncovered travel expenses and sufficient equipment to beproductive at the University, at home and abroad. Leonie Hendriks

provided much more than office support, by typing Appendix 5.3, by beinga messenger service for anything, and most importantly by her almostmotherly interest. Finally, my university room mate Werner Schippersinspired me to sharpen my thoughts, by reflecting his perception of thefield. Besides, I enjoyed his company and using his workspace.

The graduate students I partly supervised in their final assignments (JeroenJochems, Paul in t Zandt, Raymond Schrijver, Richard van der Bruggen,Barbara Stoeten, and Patrick van Rossum) brought new perspectives andcase material for my research. Raymond Schrijver and Richard van derBruggen continued to work with me after their graduation. Raymond co-authored the article on benchmarking Concurrent Engineering practices;Richard continued my work at one of the assessed companies to assist inimplementing the suggested improvements. Furthermore, apprenticeHester van de Rhoer assisted me in setting up the revised RACEquestionnaire, and post-graduate Stephan Willaert spent much time inacquiring the references for Chapters 2 and 3 that led to a jointly writtenConcurrent Engineering review article.

Outside the Eindhoven University, I received substantial support from Prof.Jo van Engelen from the University of Groningen (Groningen, TheNetherlands). He found time to discuss intermediate work, and providedclues for methodological enhancements. He also introduced me to one of his

Ph.D. students, Peter Muller. This led to a cooperatively written paper inwhich RACE is compared with NewProd, and to a personal friendship. Dr.Piet Verschuren from Nijmegen University (Nijmegen, The Netherlands)provided methodological support as well. As he was new to the field ofProduct Development, he forced me to elucidate my research objective indetail. Furthermore, Dr. Nel Wognum from the University of Twente(Enschede, The Netherlands) jointly supervised Barbara Stoetens work,which led to a joint paper on combining RACE and the Process Model ofOrganizations. Furthermore, the cooperation with Victor Paashuis, acolleague from the University of Twente, led to a successful Product

Development seminar for the Twente Quality Centre.Finally, three more people have aided to the success of this dissertation:Delmar Molenaar is the creative designer of the cover; Dirk Klaasesz andOscar Aerdts are the spirited para-nimphs during my defense.

Amsterdam, July 1996, Robert de Graaf.


14/259

Summary in Dutch

IV


15/259

Samenvatting

V

SAMENVATTING (SUMMARY IN DUTCH)

Assessen ofwel in kaart brengen, dat is het hoofdwerkwoord van ditproefschrift. Het bijbehorende lijdend voorwerp is de ontwikkeling vancomplexe producten. In algemene termen is productontwikkeling hetvertalen van markteisen of ideen naar produceerbare goederen. Metcomplexe producten wordt gedoeld op goederen die zijn opgebouwd uitzowel mechanische en elektronische onderdelen als uit software. Eenvoorbeeld is de videorecorder. Deze bestaat uit mechanische onderdelen,elektronische schakelingen en besturingssoftware. De delen werkenonderling samen, zodat de videorecorder functioneert. Met deze functionelesamenwerking dient tijdens de productontwikkeling rekening te wordengehouden.

Gedurende de productontwikkeling worden ook de kosten van een productbepaald, omdat wordt besloten welke oplossingen in detail wordenuitgewerkt. Hierbij benvloedt de keuze van basismaterialen, onderdelen enwerkwijzen de kostprijs van het product. Ook worden de productie- enservicemogelijkheden grotendeels vastgelegd en wordt bepaald hoeschadelijk het uiteindelijk afgedankte product voor het milieu is.

Het ontwikkelen van complexe producten is dus veelomvattend. Bovendienis de kans groot dat het resultaat van een bedrijf positief wordt benvloedals zijn producten slimmer worden ontwikkeld dan die van concurrenten.Hierbij zijn naast de eerder benoemde functionaliteit en kosten ook de

productkwaliteit en vooral het moment van introductie van het nieuweproduct van invloed. Zo verwerft dt bedrijf een groot marktaandeel, dateen makkelijk te programmeren, betaalbare en betrouwbare videorecorderop het juiste moment introduceert.

Binnen bedrijven wordt het ontwikkelproces van complexe producten in depraktijk verbeterd door de implementatie van nieuwe werkwijzen.Concurrent Engineering is hierbij populair. Deze werkwijze richt zich ophet zoveel mogelijk parallel uitvoeren van taken alsmede het betrekken vanlevenscyslusdisciplines om de doorlooptijd van de ontwikkeling teverkorten, de kwaliteit van het product te verhogen en de levens-

cycluskosten van het product te verlagen. Uit een uitgebreid Amerikaansonderzoek blijkt echter dat, ondanks de drang om te verbeteren, het succesvan nieuwe producten afneemt. Zo hebben de introductie vanmultidisciplinaire teams en de verbinding van teamleden met behulp vaninformatietechnologie vooralsnog niet geleid tot meer succes in de markt.Toch dienen bedrijven hun productontwikkeling te verbeteren omconcurrerend te kunnen blijven. Er bestaat dus behoefte aan een


16/259

Summary in Dutch

VI

gestructureerde methode om nieuwe werkwijzen te identificeren, die deprestatie van de organisatie wl verbeteren.

Het ontwerpen en testen van een dergelijke methode ofwel assessment ishet hoofdonderwerp van dit proefschrift. Een assessment verschaft tevens

inzicht in de problematiek rondom de ontwikkeling van complexeproducten. Inventarisatie van die problematiek is daarom het nevendoelvan dit proefschrift.

De gekozen aanpak voor het ontwerpen en testen van het assessment istweeledig:

1. onderzoek of bestaande methoden een goede uitgangspositie bieden;

Op basis van de literatuur wordt een uitgebreide lijst met criteria opgesteldwaaraan een assessment voor multidisciplinaire product-ontwikkelingmoet voldoen. Bestaande assessments worden met behulp van dezecriteria vergeleken en vervolgens wordt het beste assessment of eencombinatie van goede assessments gekozen.

2. evalueer het gekozen assessment in de praktijk.

In eerste instantie wordt de methode zelf beoordeeld en zo mogelijkverbeterd tijdens de proces-evaluatie. In tweede instantie worden deresultaten van de methode voor de beoordeelde bedrijven ingeschatgedurende de product-evaluatie.

De recente literatuur laat een aantal assessments voor productontwikkelingzien. De meeste methoden voldoen niet, omdat ze op slechts n disciplinegericht zijn. Zo wordt bijvoorbeeld het Capability Maturity Model, ontwik-

keld door het Software Engineering Institute, veel gebruikt bij hetverbeteren van softwareontwikkeling. Uiteindelijk komen er vijf methodennaar voren die gericht zijn op multidisciplinaire productontwikkeling.Feitelijk voldoet er slechts n methode redelijk aan de geformuleerdecriteria: het Readiness Assessment for Concurrent Engineering (RACE),ontwikkeld door het Concurrent Engineering Research Center.

RACE is een assessment waarmee het niveau van een multidisciplinair pro-ductontwikkelproces kan worden gevisualiseerd, bezien vanuit ConcurrentEngineering. RACE brengt de cultuur, de gehanteerde werkwijzen, demanagement-praktijken en de ondersteunende informatietechnologie in

kaart, alsmede de knelpunten die zich tijdens de productontwikkelingvoordoen. Voorts worden verbeterinitiatieven gegenereerd, die hetproductontwikkelproces kunnen verbeteren. Bij het assessment worden hetmanagement en de ontwikkelgroepen betrokken, zodat sprake is van zoweleen top-down als een bottom-up aanpak. Het management bepaalt derichting voor verbetering, de teamleden van de ontwikkelgroepen gevenknelpunten en mogelijke oplossingen aan.


17/259

Samenvatting

VII

RACE richt zich voornamelijk op het ontwikkelproces, dat wil zeggen vanproductspecificaties tot goed lopende productie. RACE richt zichnadrukkelijk niet op voorontwikkeling of marktonderzoek, noch op proces-ontwikkeling. De methode voldoet in een omgeving met ontwikkelgroepen

van 50 tot 250 personen, waarbij in elk geval marketing, product-ontwikkeling en productie zijn betrokken. Vaak zijn tevens inkoop, serviceen verkoop in deze ontwikkelgroepen vertegenwoordigd.

RACE combineert verschillende dataverzamelingstechnieken, zowel inter-views, groepssessies als vragenlijsten worden gebruikt. Het is voorinterviews en groepssessies noodzakelijk minimaal twee onafhankelijkeassessors in te schakelen. RACE is dus geen zelf-assessment.

De RACE-procedure kent de volgende stappen:

1. interviewen van het management om de doelstellingen (BusinessDrivers) voor de komende 1 tot 2 jaar te achterhalen;

2. analyseren van de documentatie en rapporten om inzicht in het proces teverkrijgen;

3. interviewen van de betrokken teamleden om knelpunten te identificerendie de realisatie van de Business Drivers in de weg staan;

4. leiden van een groepssessie met de teamleden om knelpunten teidentificeren, te clusteren en te prioriteren alsmede verbeterinitiatieven tegenereren;

5. afnemen van een vragenlijst bij de teamleden om de huidige status in hetRACE-model vast te stellen;

6. interviewen van het management om de gewenste status in het RACE-model vast te stellen.

RACE visualiseert het niveau van een ontwikkelorganisatie door middel vaneen multi-aspectmodel dat 14 dimensies beschrijft. Deze dimensies zijn op-gedeeld in een proces- en een informatietechnologie-cluster. Het proces-cluster bevat negen dimensies die op vijf niveaus worden ingeschaald. Hetinformatietechnologie-cluster bevat vijf dimensies die op drie niveaus wor-den ingeschaald.

RACE is toegepast op vier cases om een proces-evaluatie te kunnen

uitvoeren. Tijdens de eerste case kwam al naar voren dat er een stapontbrak aan RACE. Het assessment leverde wel de voorspelde resultaten op(Business Drivers, knelpunten, verbeterinitiatieven, huidige en gewenstestatus in het RACE model), maar kon niet aangeven welke verbeter-initiatieven gemplementeerd moesten worden. Daarom is een selectie-matrix ontworpen die Business Drivers, gewenste status en verbeter-initiatieven relateert om zo de meest zinvolle initiatieven te selecteren.


18/259

Summary in Dutch

VIII

De selectiematrix bestaat uit twee stappen. De eerste stap bestaat uit hetrelateren van de geprioriteerde Business Drivers aan de gewenste status inhet RACE-model, om vast te stellen in hoeverre deze gewenste statusaansluit op de Business Drivers. De prioriteit van de Business Drivers wordt

zo overgebracht op de gewenste status. De tweede stap bestaat uit hetrelateren van de gewenste status aan de verbeterinitiatieven. Hierbij wordtweergegeven in hoeverre elk verbeterinitiatief een bijdrage levert aan hetbereiken van de gewenste status. De prioriteit van de gewenste status wordtzo overgebracht op de verbeterinitiatieven. Vervolgens wordt onderzocht ofde verbeterinitiatieven te combineren zijn of juist elkaar uitsluiten. Tenslottewordt een beperkt aantal initiatieven geselecteerd, dat gezamenlijk eensubstantile bijdrage kan leveren aan het bereiken van de gewenste status.

De selectiematrix is toegepast op de eerste case en vervolgens als zevendestap toegevoegd aan de RACE-procedure. Hierna is de uitgebreide RACE-procedure in drie cases toegepast. Na deze cases is de methodegevalueerd. In deze zogenaamde proces-evaluatie kwamen drie puntennaar voren:

1. de RACE-procedure dient te worden gestroomlijnd door de betrokkenenvr elke stap te voorzien van informatie, zodat eenieder zich beter ophet interview of de groepssessie kan voorbereiden;

2. de RACE-vragenlijst voor het proces-cluster dient verbeterd te wordendoor van een dichotome (ja/nee) vraagstelling over te gaan op een vijf-punts schaal, zodat de antwoordcategorien beter aansluiten op debeleving van de teamleden;

3. het RACE-model dient te worden uitgebreid met twee dimensies omdatde knelpunten die in cases 1 tot en met 4 naar voren zijn gekomen, nietvolledig aan de dimensies van het RACE-model konden worden gerela-teerd. Er bleek te weinig aandacht te zijn voor strategieontplooiing envoor ondersteuning bij het werken met productarchitecturen.

RACE is op basis van deze bevindingen verbeterd. De verbeterde methode isRACE II genoemd. RACE II bestaat dus uit zeven stappen en gebruikt eenmodel met 16 dimensies. Dit model wordt in figuur 1 weergegeven. Bovende horizontale streep staan de proces-dimensies, die op vijf niveaus wordeningeschaald. Onder de streep bevinden zich de informatietechnologie-

dimensies, die op drie niveaus worden ingeschaald. Elke dimensie bestaatuit drie tot zes criteria. Deze criteria worden gemeten met behulp van devragenlijst.


19/259

Samenvatting

IX

Cordinatie-

ondersteuning

Integratie-ondersteuning

Klantgerichtheid

Aandacht voor de keten

Teamvorming & ontwikkeling Plaats van teams in de organisatie

ManagementsystemenProductkwaliteit &

standaarden

Aanpassingsvermogen

Managementondersteuning

Discipline

PROCES

INFORMATIETECHNOLOGIE

Informatiebeheer

Communicatie-

ondersteuning

Strategie-ontplooiing

Toepassingsgerichte

Software

Ondersteuning voor

Productarchitectuur

OptimaliserendOptimaliserend

GemetenGemeten

GeavanceerdGeavanceerd

VastgelegdVastgelegd

UitgebreidUitgebreid

HerhaalbaarHerhaalbaar

BasisBasis

Ad HocAd Hoc

Figuur 1 - Het RACE II Model

Tijdens de ontwikkeling van RACE naar RACE II dienden zich nog twee casesaan. Het betrof hier cases uit n bedrijf, waarvan n ontwikkelgroep (case5) net een verbeteringsprogramma had afgesloten en hoog scoorde op de

prestatie-indicatoren van het bedrijf. De andere ontwikkelgroep (case 6) mettraditionele werkwijzen scoorde daarentegen laag. De situatie bood bijuitstek de gelegenheid om de discriminerende werking van het RACE-modelte bestuderen. Case 5 bleek inderdaad relatief hoog te scoren in het R ACE-model; de hoogste score die tot nu toe is gemeten. Case 6 scoorde behoorlijklager in het RACE-model. De verschillen tussen beide cases konden ookdaadwerkelijk worden verklaard uit de gemplementeerde verbeteringen.

Het inzicht in de discriminerende werking van het RACE-model is gebruikttijdens de product-evaluatie met RACE II. Hierbij is in een viertal organisa-ties een assessment uitgevoerd. De aandacht ging voornamelijk uit naar de

resultaten van RACE II voor de respectievelijke bedrijven. Het toepassen vanRACE II leidde weliswaar niet tot directe verbetering, maar wel tot inzicht inde bestaande problematiek. Ook werden verbeterinitiatieven zichtbaar diein lijn waren met de doelstellingen van het bedrijf. Na de assessmentsdienden de vier organisaties zelf tot ontplooiing van de geselecteerdeverbeterinitiatieven over te gaan door middel van het opstellen vangedetailleerde verbeterplannen. Voorwaarde hierbij was dat de resultaten


20/259

Summary in Dutch

X

van het assessment door de managers en door de teamleden wordengedragen.

Om de acceptatie van de assessmentresultaten en de ontplooiing van deverbeterinitiatieven te bepalen, zijn acht product-evaluatiecriteria ont-

wikkeld. Deze criteria zijn vervolgens gemeten in de vier cases. Uit demetingen bleek dat met name de overgang van assessment naar ontplooiingzeer moeizaam gaat. Bij de laatste case is het ontplooiingsproces van nabijgevolgd om inzicht te krijgen in de redenen hiervoor. Het bleek dat hetuitwerken van verbeterinitiatieven veel tijd en moeite kostte. In elk gevalwas de inspanning vele malen groter dan tijdens het assessment en trok hetuitwerken van de initiatieven een zware wissel op de bestaande organisatie.Verbetering was namelijk niet de eerste interesse van ontwikkelaars en hunmanagers. Zeker als lopende projecten dreigden uit te lopen werdstructurele verbetering (soms tijdelijk) gestopt.

Op basis van de cases kan worden gesteld dat RACE II een geschiktassessment is voor het in kaart brengen van productontwikkelprocessenwaarbij verschillende disciplines zijn betrokken. De 16 dimensies van hetmodel dekken de problematiek van de tien cases goed af, waarbij isvastgesteld dat er duidelijk meer aandacht is voor proces-gerelateerdeverbetering dan voor informatietechnologie-gerelateerde verbetering. Metde selectiematrix kan RACE II bovendien aangeven welke verbeter-initiatieven van de teamleden het beste aansluiten bij de doelstellingen vanhet management. RACE II heeft echter nog een paar minder sterke kanten.Hierbij valt te denken aan de validiteit en betrouwbaarheid van devragenlijst die kan worden verbeterd alsmede het ontbreken van richtlijnen

ten behoeve van het management voor het stellen van doelstellingen.Wordt specifiek naar de tien cases gekeken dan valt een aantal zaken op:

90% van de cases heeft als n van de doelstellingen het verlagen van delevenscycluskosten van het product; 70% van de cases wil de kwaliteitvan het product verhogen en slechts 50% wil de doorlooptijd van deproductontwikkeling verkorten;

zeven van de tien cases laten team-gerelateerde knelpunten zien; zescases hebben planning-gerelateerde knelpunten en vijf cases hebbenproblemen met betrekking tot de specificaties, de ontwikkelprocedure en

de ontwikkelstrategie aangegeven. Opvallend is dat slechts in tweegevallen vergelijkbare informatietechnologie-gerelateerde knelpuntennaar voren komen;

geen van de cases stijgt in het RACE-model op de procesdimensies uitboven het niveau Vastgelegd. Elke case heeft zelfs twee of meerdimensies op het laagste niveau Ad Hoc liggen. Het verbeteren vanproductontwikkeling heeft hier nog een lange weg te gaan;


21/259

Samenvatting

XI

de geselecteerde verbeterinitiatieven vertonen bij de tien cases minderovereenkomsten dan bij de doelstellingen en de knelpunten het geval is.Toch is het verbeteren van de teams in zeven cases geselecteerd. Verderkomt een intensieve projectstart vijf maal naar voren en worden

verbeterd projectmanagement, verbeterde ontwikkelprocedures, en hetgebruik van prototypingtools drie maal geselecteerd als verbeterinitiatief.

Tot slot van deze samenvatting een korte leeswijzer voor het proefschriftper hoofdstuk:

1. leidt de probleemstelling in en presenteert de onderzoeksvragen. Vervol-gens wordt de onderzoeksaanpak theoretisch onderbouwd;

2. gaat dieper in op productontwikkeling door een definitie van het proceste geven en door in te gaan op een aantal ontwikkelmethodologien.Daarna worden de uitdagingen voor hedendaagse productontwikkelinggeschetst en wordt uitgebreid ingegaan op Concurrent Engineering;

3. stelt op basis van een uitgebreide literatuurstudie de criteria vast voor hetevalueren van productontwikkel-assessments. Vijf bestaande assessmentsworden vervolgens vergeleken op basis van deze criteria en RACE wordtals beste gedentificeerd;

4. past RACE toe in de praktijk van de productontwikkeling. Eerst wordende RACE-procedure en het RACE-model beschreven, vervolgens wordtcase 1 uitgebreid behandeld. Op basis van case 1 wordt dan de selectie-matrix ontworpen en toegepast op die case. Cases 2 tot en met 4 wordenhierna beschreven, waarop de proces-evaluatie volgt. Hierin wordenverbeteringen voor de RACE-procedure en het RACE-model gepresen-teerd;

5. laat eerst de discriminerende werking van het RACE-model zien op basisvan cases 5 en 6. Vervolgens wordt RACE IIuitgebreid gepresenteerd, metprocedure, model, criteria en niveaus. Hierna wordt RACE II toegepast opcases 7 tot en met 10, waarbij per case een product-evaluatie wordtgedaan;

6. biedt een methodologische inbedding van de resultaten van het onder-zoek, waarbij de onderzoekswaarden, de validiteit en betrouwbaarheidvan het onderzoek alsmede de generaliseerbaarheid van de resultatenworden besproken;

7. presenteert de conclusies met betrekking tot de onderzoeksvragen, geefthints voor toekomstige assessments en geeft weer hoe dit onderzoek zoukunnen worden voortgezet.

Veel leesplezier toegewenst!


22/259

Summary in Dutch

XII


23/259

XIII

Table of Contents

1. Introduction ____________________________________________________1

1.1 Need for Improving Product Development ______________________________ 1

1.2 Problem Statement ___________________________________________________ 3

1.3 Research Objective____________________________________________________ 4

1.4 Research Design______________________________________________________ 6

1.4.1 Design Research Cycle ___________________________________________ 6

1.4.2 Process and Product Evaluation ___________________________________ 7

1.5 Dissertation Overview _______________________________________________ 10

2. Product Development ___________________________________________11

2.1 Introduction ________________________________________________________ 11

2.2 Definition & Delimitation of Product Development ______________________ 11

2.3 Design Methodology_________________________________________________ 15

2.4 Challenges for Product Development __________________________________ 20

2.5 Concurrent and Collaborative Engineering______________________________ 22

2.5.1 History________________________________________________________ 22

2.5.2 Collaborative Engineering: CE in a Wider Context __________________ 24

2.5.3 Application of Concurrent Engineering ____________________________ 26

3. Product Development Assessments________________________________29

3.1 Introduction ________________________________________________________ 29

3.2 Criteria for Product Development Assessments__________________________ 30

3.2.1 Requirements for Product Development Assessment Results _________ 31

3.2.2 Requirements for Product Development Assessment Methods________ 31

3.2.3 Requirements for Product Development Assessment Models _________ 33

3.2.4 Criteria Review_________________________________________________ 40


24/259

XIV

3.3 Product Development Assessment Methods _____________________________42

3.3.1 Mentor Graphics Concurrent Engineering Assessment ______________42

3.3.2 Simultaneous Engineering Gap Analysis (SEGAPAN) _______________43

3.3.3 Readiness Assessment for Concurrent Engineering (RACE)____________443.3.4 Practical Approach to Concurrent Engineering (PACE) ______________45

3.3.5 Extended RACE _________________________________________________46

3.4 Assessment Evaluation and Selection ___________________________________47

4. Process Evaluation of RACE______________________________________51

4.1 Introduction_________________________________________________________51

4.2 Readiness Assessment for Concurrent Engineering (RACE) ________________53

4.2.1 RACE Procedure_________________________________________________53

4.2.2 RACE Model ____________________________________________________56

4.2.3 RACE Terminology ______________________________________________57

4.3 Test-case: Case 1 _____________________________________________________59

4.3.1 Business Drivers ________________________________________________59

4.3.2 Corporate Documentation________________________________________59

4.3.3 Interview Bottlenecks and Remedies_______________________________59

4.3.4 Group Session Bottlenecks and Remedies __________________________60

4.3.5 Process and Technology Questionnaire ____________________________614.3.6 Desired State ___________________________________________________61

4.4 Development of the Improvement Selection Matrix_______________________62

4.5 Amended RACE Method in Case 2, Case 3, and Case 4 ____________________68

4.5.1 Business Drivers ________________________________________________69

4.5.2 Bottlenecks_____________________________________________________69

4.5.3 Remedies ______________________________________________________71

4.5.4 Current and Desired States _______________________________________72

4.5.5 Useful Remedies ________________________________________________74


25/259

Preface

XV

4.6 RACE Procedure Shortcomings and Improvements _______________________ 76

4.6.1 Business Drivers Interviews______________________________________ 76

4.6.2 Corporate Documents Reviews ___________________________________ 77

4.6.3 Bottleneck/Remedy Interviews___________________________________ 774.6.4 Bottleneck/Remedy Group Sessions ______________________________ 78

4.6.5 Questionnaire __________________________________________________ 79

4.6.6 Desired State Interview__________________________________________ 79

4.6.7 Remedy Selection_______________________________________________ 80

4.7 RACE Model Shortcomings and Improvements __________________________ 81

4.7.1 Approach______________________________________________________ 81

4.7.2 Linking Bottlenecks to the RACE Model ____________________________ 82

4.7.3 Addition of the Dimension Strategy Deployment ___________________ 854.7.4 Addition of the Dimension Product Architecture Support ____________ 87

4.8 Summary___________________________________________________________ 89

5. Product Evaluation of RACE______________________________________91

5.1 Introduction ________________________________________________________ 91

5.2 RACE at Case 5 and Case 6 ____________________________________________ 93

5.2.1 Bottlenecks ____________________________________________________ 94

5.2.2 Current and Desired States_______________________________________ 955.2.3 Useful Initiatives _______________________________________________ 96

5.3 Discrimination in RACE Model ________________________________________ 97

5.4 RACE II ____________________________________________________________ 102

5.4.1 RACE II Procedure _____________________________________________ 102

5.4.2 RACE II Model_________________________________________________ 106

5.5 RACE II Product Evaluation __________________________________________ 110

5.6 Product Evaluation Criteria __________________________________________ 111

5.7 Case 7_____________________________________________________________ 1125.7.1 RACE II Application ____________________________________________ 112

5.7.2 Product Evaluation ____________________________________________ 115

5.8 Case 8_____________________________________________________________ 117

5.8.1 RACE II Application ____________________________________________ 117

5.8.2 Product Evaluation ____________________________________________ 120


26/259

XVI

5.9 Case 9 _____________________________________________________________122

5.9.1 RACE II Application ____________________________________________122

5.9.2 Product Evaluation_____________________________________________126

5.10 Case 10 ___________________________________________________________1275.10.1 RACE II Application ___________________________________________127

5.10.2 Product Evaluation____________________________________________133

5.11 Summary _________________________________________________________136

6. Discussion ____________________________________________________139

6.1 Introduction________________________________________________________139

6.2 Research Values ____________________________________________________139

6.3 Methodological Research Evaluation __________________________________140

6.3.1 Shift in Research Objective ______________________________________141

6.3.2 Research Validity & Reliability___________________________________141

6.3.3 Research Criteria_______________________________________________143

6.3.4 RACE Questionnaire ____________________________________________144

6.4 Practical Research Evaluation_________________________________________145

6.5 Generalizibility _____________________________________________________146

7. Conclusion____________________________________________________149

7.1 Introduction________________________________________________________149

7.2 Research Objective __________________________________________________149

7.3 Lessons Learned ____________________________________________________160

7.3.1 Method _______________________________________________________160

7.3.2 Cases_________________________________________________________161

7.4 Further Research____________________________________________________162


27/259

Preface

XVII

References ______________________________________________________167

Appendices _____________________________________________________177

Appendix 3.1 Evaluation of Product Development Assessments _____________ 179Appendix 5.1 Case 5 and Case 6 RACE Profiles____________________________ 183

Appendix 5.2 RACE II Questionnaire ____________________________________ 185

Appendix 5.3 RACE II Dimension and Criteria Definitions __________________ 196

Appendix 5.4 Case 4 and Case 10 Profiles _________________________________ 225

Curriculum Vitae ________________________________________________229


28/259

XVIII


29/259

1

1. INTRODUCTION

1.1. Need for Improving Product Development

Product Development enables manufacturing companies to respond tochanges in the market. New products, improved products, extensions andenhancements of products all empower a company to maintain acontinuous flow of products to the market that can satisfy changingcustomer needs (Vesey, 1991).

Product Development is one of the 7 phases generally recognized in NewProduct Development (NPD) by manufacturing companies. Johne (1984)describes phases 1 to 4--Concept Search, Concept Screening, Concept

Testing and Business Analysis--as initiation phases. Phase 5 is ProductDevelopment, which constitutes the implementation phases combined withProduct Use Testing and Commercialization (Page, 1993).

The Product Development phase is especially significant for the success ofcompanies that manufacture mature, complex products (e.g., cars, copiers,and video recorders). Erens (1996) implies such products require carefulconsideration of different technologies during Product Development tomeet customer requirements. Ehrenspiel (1991) and Hollingum (1989)indicate that Product Development largely determines the quality and costof complex products. In addition, Vesey (1991) illustrates Product

Development has the largest influence on the introduction time of a newproduct.

Cost, quality, and time jointly determine the success of new products.Product Development managers are therefore pushed to introduceimprovements. Just optimizing the Product Development department withtools to enhance efficiency, such as Computer Aided Design, will not lead tothe desired improvement. Product Developments impact on downstreamactivities such as production, sales, service, and disposal also need to beconsidered carefully (Vesey, 1991; Penev, 1996). If this influence is notconsidered during Product Development, the number of changes necessary

at the end of the Product Development phase will be tremendous. Thesechanges not only postpone the introduction date of the new product, butwill also increase the product cost and lower its quality.

Pages (1993) review of 189 North American companies provides animpression of the way companies are coping with the pressure to developlow-cost, high-quality products in the shortest possible time. This reviewconcentrates on the level of overall new product programs. The review isaimed at three major issues: the organizational structures and compensation


30/259

Introduction

2

plans used for NPD; the processes used for managing the development ofnew products; and the performance of the companies new productprograms. The survey was mainly completed by general managers (36%),marketing managers (25%), and technical managers (23%). In 1968 and 1982

similar surveys were published, so a comparison with earlier results ispossible (Booz, Allen and Hamilton, 1968, 1982).

The institution of multi-disciplinary teams in 76% of the respondents is oneof the major results reported. These teams mainly consist of Marketing,Research & Development, and Engineering representatives. Downstreamdepartments are much less involved: Manufacturing in 42%, Sales in 24%,and Service in less than 6% of the cases.

The companies surveyed reported more use of a new product strategy and aformal development process than in earlier surveys, but 32% still hadneither. Nearly 41% of the companies in the survey had managed to

accelerate their NPD process over the past 5 years. However, the processphases still are merely sequential with only 10% overlap. ProductDevelopment is the most extensive phase and accounts for 36% of the totallead-time. In the implementation phases, it even consumes 53% of the lead-time.

Obstacles to successful NPD are also reviewed. The results show 39% of thecompanies struggle with the resources provided for NPD; basically,financial and human resources are considered as well as lack ofengineering, market research or design resources. This obstacle did notoccur in earlier surveys. Table 1.1 states the major obstacles found in the

survey (Page, 1993).Table 1.1 - Obstacles to Successful New Product Development

Obstacles % of Cases

1. Resources (financial, human, capabilities) for New Product Development 39.2

2. Activities within the New Product Development process 28.6

3. Top management role or support in Product Development 25.4

4. Role of Marketing in New Product Development 19.6

5. Management or organization for New Product Development 16.9

6. Risk in New Product Development or company risk attitude 15.9

7. Bureaucratic nature of the organization 12.7

8. Short-term outlook or orientation 6.9

9. Communications in New Product Development 6.9

10. Time available to do new product work 6.3


31/259

Chapter 1

3

Although better practices have been implemented, the success rate of newproducts has declined from 67% in 1962 and 65% in 1982 to 58% in the 1990survey. Page (1993) assumes this decline is, at least in part, attributable tointensified competition. Due to competitive pressure, the responding

companies expect that sales from products introduced in the last 5 yearshave to rise from 32% to 38% of total sales. Furthermore, the respondentsindicate sales from new product acquisitions will rise as well, from 9% to13%. This indicates companies anticipate a growing reliance on NPD.

From Pages review it can be concluded that further improvement of theNPD process is necessary. However, the improvements implemented from1982 to 1990 have not led to the improved success of new products. Thiscould mean that either the wrong initiatives were implemented, or that thepace of implementing improvements was too slow to keep up with thechanges in the environment. In any case, improving NPD remains crucial tostop the product success rate from plunging further.

When mature, complex products are concerned, the success of a newproduct is strongly determined during the implementation phases. AsProduct Development is the most eminent of the implementation phaseswhen quality, lead-time and cost are concerned, this thesis will be focusedon improving Product Development.

1.2. Problem Statement

Companies that manufacture complex products can hardly improveProduct Development practices in time to cope with the market pressuresexperienced. Some practices, that are advocated in literature, such as multi-disciplinary teams, are implemented, yet these practices do not lead tooutstanding performances.

During the development of complex products multiple issues are to beresolved:

Complex products require several engineering disciplines to master thedesign, e.g. software development, mechanical and electrical engineering.These disciplines must be able to coordinate their development efforts(Erens, 1996).

Down-stream implications of the design, e.g. for production, sales,

service, and disposal--must be considered to prevent numerousengineering changes late in the Product Development phase (Vesey, 1991;Penev, 1996).

Product cost, quality and introduction date must be managed to ensuresuccessful commercialization of a new product (Ehrenspiel, 1991;Hollingum, 1989; Vesey, 1991).


32/259

Introduction

4

The way in which companies resolve these issues is unclear. Manypublications present successfully implemented new practices, e.g. Ellis(1993), Erkes (1993), Nevens (1990), and Sprow (1992). Other publicationssuggest standardized solutions for improving the practices, e.g., Dicesare

(1993), Leonard-Barton et al. (1994), Pugh (1991), and Wheelwright andClark (1992). Still, these publications do not illustrate why certain practicesare implemented or under which conditions a certain approach to ProductDevelopment will be successful. Furthermore, implementing acceleratedProduct Development practices can lead to hidden cost, because, e.g.,breakthrough innovations are driven out, or people cost are boosted(Crawford, 1992).

Product Development managers are thus faced with the followingquestions:

How can the status of the Product Development practices be revealed?

Which improvements should be implemented to improve these practices? How can the results of these improvements be monitored?

These questions are brought forward by the Dommelgroep, a consortium ofProduct Development managers, representing Dutch manufacturers ofcomplex products. These managers doubted the successes published andthe standardized solutions, and acknowledged Pages conclusion ofdeclining product success and Crawfords proposition of hidden costs inimproving Product Development practices.

A method that structures the assessment of the questions stated above is

needed to provide these insights. Such methods are used in practice at themoment; the Capability Maturity Model (CMM) and the European QualityAward (EQA) are known examples (Humphrey, 1989; EuropeanFoundation of Quality Management, 1995). These methods are, however,less suitable for assessing Product Development practices of complexproducts manufacturers. They do not have the right level of abstraction.Methods such as CMM consider one specific Product Developmentdiscipline, in this case software development. EQA and alike methodsconsider the entire organization and do not assess Product Developmentpractices in detail. To support the analysis of Product Developmentpractices a dedicated assessment method is desired at the new product

program level.

1.3. Research Objective

This research considers two objectives. The primary objective of this studyis to develop and test an assessment method that can aid management inanalyzing the current Product Development practices of complex productmanufacturers. Furthermore, the assessment method should identify


33/259

Chapter 1

5

suitable improvements for the company. Finally, the assessment methodshould provide measures to ensure that the improvements are successfullyimplemented and thus provide better practices and increased new productsuccess.

The primary research questions are:1.1. Which Product Development practices should be reviewed to provide a

comprehensive starting point for improvement, when complex productsare considered?

These practices should constitute the dimensions of the assessment method.

1.2. How can practice improvements be identified that are suitable for acomplex product manufacturer, and what determines this suitability?

The improvements generated by the method should not only lead to betterpractices but also to increased product success.

1.3. How can the achievements of the improvements identified bemonitored such that better practices and increased product success arein fact accomplished by the complex product manufacturers?

Measures provided by the method should guide implementation of theimprovements and demonstrate the success.

The secondary research objective addresses the use of such a method inpractice. By application of the assessment method, some indications couldbe found to explain why companies improve slowly or choose to implementless suitable improvements. Furthermore, the existence of the generalobstacles for successful Product Development published by Page (1993) canbe verified. Finally, the value of standard solutions can be examined.

Application of the method brings forward the following secondary researchquestions:

2.1. How can the decreased product success be explained whileimplementing improved practices using the cases in which the methodwas applied?

2.2. Which obstacles can be identified that prevent companies fromachieving successful Product Development for the cases in which themethod was applied?

2.3. Which standard solutions are useful to improve Product Developmentfor the cases in which the method was applied and under whichconditions?

1.4. Research Design

The research design is driven by the primary research objective--to developand test an assessment method for the analysis and improvement of


34/259

Introduction

6

Product Development practices. However, the research design allows forsome attention to the secondary research questions. The secondary researchobjective can therefore only be studied partly. Still, the material from theprimary research objective can provide useful insights for the secondary

objective.The primary research objective contains two verbs: develop and test. Theseactivities are carried out with different research designs. First, thedevelopment of the tool is executed using the design research cycle type,defined by Van Engelen and Van der Zwaan (1994). The research design forthe theoretical part of this dissertation in presented in the next sub-section.Second, the testing of the tool in practice is executed using the processevaluation and product evaluation research types, defined by Verschuren(1994). These research types are further elucidated in the second sub-section.

1.4.1. Design Research CycleThe development of the assessment method follows the design researchcycle that consists of five basic steps:

1. Setting the design goal.

The design goal must comply with three basic prerequisites, it must bemeasurable, feasible and profitable. First, criteria must be defined thatcan measure the success of the method. In general terms, this is measuredby reviewing the improvements that are started after the assessment.Second, the designed assessment method will be based upon existingassessment methods to ensure feasibility of the design. This way suitableelements can be reused as much as possible. Third, the assessedcompanies must benefit from the assessment results. Reassessing acompany when improvements are implemented is used to measure thesebenefits.

2. Setting up the design specifications.

Assessment design specifications are set up for the procedure, thedimensions, and the alignment with the primary research objective. Ineach of these three categories, lists of largely qualitative specifications aredefined, mainly based on general assessment literature and published

Product Development practices. These lists are reviewed fordiscrepancies among the specifications. Furthermore, the attainability ofthe specifications and completeness of the lists are addressed. Eachspecification is rated on a three-level scale to indicate its relativeimportance for selecting suitable assessment components.


35/259

Chapter 1

7

3. Generating alternative designs.

Five recently developed assessment methods claim to be suitable forimproving Product Development practices. These assessments areevaluated for their fit with the specifications defined in step 2.

4. Selecting from alternatives.Only a few of the specifications defined in step 2 are of a quantitativenature. Choosing the assessment with optimal performance is thereforenot possible. Thus, the five assessments are evaluated for the extent towhich they satisfy a certain specification. Again, three levels are definedto indicate the relative satisfaction of a specification by each assessment.

5. Reporting.

The way in which the specifications mentioned above are constructed,where and how alternative assessments are found, how the selection is

accomplished, and which assumptions are used, is detailed in Chapter 3of this dissertation.

1.4.2. Process and Product Evaluation

The assessment that is chosen in the design research cycle can now beevaluated in practice. Verschuren (1994) distinguishes two basic types ofpractical evaluations: process evaluations and product evaluations. Productevaluations address the results of a certain intervention, while processevaluations address the intervention itself. Product evaluations are mainlyfocused on legitimizing the effect of an intervention; process evaluationspursue improvement of an intervention.

An assessment basically is an intervention in practice. In the design researchcycle the selected assessment is merely evaluated for its theoreticalcapabilities. This only indicates face validity of the method, as applicationalrequirements are not tested. Therefore, a second design cycle is necessarybefore the assessment results can be evaluated: a process evaluation toimprove the applicational qualities of the assessment.

The process evaluation addresses the procedure and the dimensions of thechosen assessment. Four cases are assessed with the primary focus on lacksin the procedure and missing dimensions. The material from these casescompletely determines this evaluation, as criteria for process evaluationscannot be defined beforehand (these criteria would have been reviewed inthe design research cycle, if they were available). Therefore a qualitativeapproach, using interviews and observation, is followed whilecharacterizing improvements. These improvements are implemented in anenhanced assessment method. The process evaluation is presented inChapter 4.


36/259

Introduction

8

The product evaluation addresses the results of the assessment. Two majorprerequisites for a product evaluation are that the participants understandthe accomplishment of the assessment results, and that the assessmentpresents integral knowledge of the case (Verschuren, 1994). Two

supplementary cases are assessed to comply with these prerequisites. Theproduct evaluation itself is based upon four additional cases. These casesare assessed with the improved method to determine whether theimprovements defined by the assessment are legitimate. In general terms,criteria for this evaluation are the acceptance of the results by theorganization, the decision on implementing the improvements, institutingimprovement projects, and the use of metrics to ensure successfulimprovement. For the product evaluation, a qualitative approach is taken aswell, because the product is evaluated for four unique cases (Verschuren,1994). Interviews and observations determine the ratings for each metricdefined. Chapter 5 provides the product evaluation.

The ten cases presented are all studied with a structured format, theassessment method. In the terms of Yin (1994), this replicated designprovides means to generalize towards the secondary research questions. Foreach case, the assessments describe the improvement goals, obstacles,improvements, and a measured as well as a desired status of the assesseddimensions. This format provides results that can be compared across thecases. Commonalties and differences between cases can thus be analyzed.From this analysis, research questions 2.2 (relating to obstacles) and 2.3(relating to standard solutions) can be answered in part. For researchquestion 2.1 some indications could be found in the last four cases, as the

results of the chosen assessment method are evaluated.The use of case studies poses some problems according to Hgg andHedlund (1978). The basic issue is the scientific control over case studyoutputs. Seven recommendations are suggested to assure some control overthese outputs. For each of these topics the case study design used iscommented upon.

1. Cases should be consciously chosen.

A list of 15 complex product manufacturers in north-west Europe wasgenerated before the assessments are started. These manufacturers wereinvited to participate in the assessments. Four companies participated inan assessment. After publication of the first results, four additionalcompanies requested assessments. Three of these companies had beeninvited to participate earlier. All companies were assessed, but two of thetwelve assessments are not presented here. One did not concern acomplex product manufacturer; the other was not carried out inaccordance with the assessment procedures presented in this dissertation.


37/259

Chapter 1

9

The results of these assessments are briefly presented in the discussion(Chapter 6).

2. The context of the cases should be delimited.

In eight cases the context is an operational unit, where marketing,

development, and manufacturing capabilities are involved at the veryleast. Exclusively development practices are reviewed, not the marketingor manufacturing practices. The remaining two cases focus on confineddevelopment activities (system design and production preparation). Still,in these cases marketing, development, and manufacturing capabilitiesare involved as well.

3. Distance to the pressure of the case should be maintained by theresearchers.

The distance to the pressure of the organization was kept in every case, asno operational tasks were executed. Furthermore, the assessments werealways carried out by at least two researchers, that were not on the payroll of the assessed company. Furthermore, only one assessor wasinvolved full time. As the assessors jointly defined the results, limitedinvolvement with the case was assured.

4. A general framework to relate case study observations to should beprovided.

The assessment produces comparable results for all cases, because itsmethod is standardized. The observations all serve predefined goals;these are the frameworks to which to results are related.

5. The case studies should be related to outside knowledge.The assessment relates each case studys results to predefineddimensions. This way unbiased information is used to verify theobserved practices.

6. The frameworks used should be evaluated continuously.

This issue is only partly addressed in the cases studied. During theprocess evaluation (cases 1 to 4) the frameworks of the assessment areaddressed continuously. For the remaining cases these frameworks arenot systematically discussed. However, in the discussion of this

dissertation a retrospective view to these cases is presented.7. The researchers values should be explicated during the case studies.

The continuous evaluation of frameworks can also lead to explication ofthe researcher values. These values should preferably be stated after eachcase. This dissertation only reviews these values systematically afterCases 1-4. In the discussion of this dissertation a broader application ofthe assessment is argued and the research values are explained.


38/259

Introduction

10

1.5. Dissertation Overview

The remainder of this dissertation consists of 6 chapters. In Chapter 2Product Development is defined, methodologies are presented and therecent dynamics of this NPD phase are discussed. Chapter 3 outlines the

specifications for Product Development assessments and appraises theperformance of five existing Product Development assessment methodswith regard to these specifications. Cases 1 to 4 are presented in Chapter 4,the process evaluation of the chosen assessment. The product evaluation ofthe assessment results, based on Cases 5 to 10, is illustrated in Chapter 5.The discussion in Chapter 6 considers the research evaluation as well as thegeneralizations and the applicability of the evaluated assessment. Finally,Chapter 7 answers the research questions, provides lessons learned fromthe assessments and indicates opportunities for further research. Figure 1.1provides a schematic overview of this dissertation.

Chapter 2: Product Development

Product Development Definition and Methodology.

Dynamics of Product Development in Terms of Time, Quality, and Cost.

Practices to Improve Product Development: Concurrent and Collaborative Engineering.

Chapter 3: Product Development Assessments

Chapter 4: Process Evaluation of RACE

Chapter 5: Product Evaluation of RACE

Chapter 6: Discussion

Chapter 7: Conclusion

Definition of Product Development Assessment Specifications Conform Research Objective.

Presentation and Evaluation of Product Development Assessments.

Most Suitable Assessment: Readiness Assessment for Concurrent Engineering (RACE).

RACE Procedure and Model; Test Case 1: Development of Improvement Selection Matrix. Application of RACE in Cases 2 to 4.

Process Evaluation of RACE: Procedure and Model Improvenments.

Discrimination in the RACE Model: Application of RACE in Cases 5 and 6.

Amended Procedure and Model: RACE II.

Product Evaluation of RACE: Application of RACE II in Cases 7 to 10.

Research Values.

Methodological Research Evaluation in Terms of Validity and Reliability.

Practical Research Evaluation; Generalizations and Applicability of RACE: Cases 11-12.

Fulfillment of Primary and Secondary Research Objectives.

Lessons Learned from Assessing Cases 1-10.

Indications for Further Research.

Figure 1.1 - Overview of this Dissertation


39/259

11

2. PRODUCT DEVELOPMENT

2.1. Introduction

The field of this dissertation is Product Development. Chapter 1 describesProduct Development as a phase of the New Product Development Process.Product Development is, however, a process as well, which converts marketneeds to manufacturable products (Wallace, 1990). Many definitions forProduct Development exist, so therefore delimitation of the field of researchis required. Section 2 delimits Product Development, by putting the processin its context, segregating it from research and pre-development, andproviding a working definition for this dissertation.

The Product Development process consists of several key activities that arelinked through design methods. Various design methods exist and togetherform design methodology. Section 3 briefly reviews design methodology toprovide insight into the execution and management of ProductDevelopment activities.

Market needs strongly influence Product Development. Just increasingproduct functionality does not guarantee product success. The productmust be introduced at the right time, with high quality and at low cost.Furthermore, manufacturers must consider the environmental effects of theproduct. These challenges for Product Development are presented in section

4.Companies respond to these challenges by looking for new ProductDevelopment practices. In literature, Concurrent Engineering (CE) is oftenpresented as the ideal philosophy to improve Product Development(Winner et al., 1988; Cleetus, 1992). CE mainly advocates the involvement ofdown-stream stages, such as production and service, and the concurrentexecution of development activities. This context of CE appears to belimited to optimizing internal activities. Information Technologyapplications and supplier involvement can also contribute to theimprovement of Product Development performance. Therefore,

Collaborative Engineering is introduced to put CE in a wider context.Section 5 discusses Concurrent and Collaborative Engineering, as well asthe difficulties found in implementing it.

2.2. Definition & Delimitation of Product Development

The process of Product Development has multiple definitions in literature.Hales (1991) emphasizes that Product Development terminology is hard toaddress adequately, because Product Development and design terms tend


40/259

Product Development

12

to vary in meaning according to discipline, context and interpretation.Consequently, Product Development is used synonymous for design andengineering design, for example. This can be explained by comparingdefinitions. Finkelstein and Finkelstein (1983) define design as:

...a sequence of stages starting from the perception of a need andterminating in a final firm description of a particular design configuration.Each stage is in itself a design process and is an iterative sequence of steps.

The English Department of Scientific and Industrial Research (1964)presents a comprehensive definition for engineering design:

... use of scientific principles, technical information and imagination in thedefinition of a mechanical structure, machine or system to perform pre-specified functions with the maximum economy and efficiency.

These definitions are often referred to but do not address the commercialimportance of developing new products. Wallaces definition (1990) ofengineering design does indeed consider commercial issues:

Engineering Design is the process of converting an idea or market need intothe detailed information from which a product or system can be produced.

These definitions do not consider the impact of Product Development onsubsequent activities of the life-cycle. The number of solutions ProductDevelopment can provide is, however, limited by these life-cycle processes(Vesey, 1991). The working definition for Product Development in thisdissertation is based on the above definitions, but also includes therestrictions that apply:

Product Development is a sequence of design processes that converts generallyspecified market needs or ideas into detailed information for satisfactory

manufacturable products, through the application of scientific, technical and creative

principles, acknowledging the requirements set by succeeding life-cycle processes.

Research and pre-development are often seen as early stages in ProductDevelopment. However, research--the process of identifying newtechnologies and devising possible applications--is not a part of ProductDevelopment, but might initiate it. Research can be a part of the ConceptSearch phase defined by Page (1993). Pre-development--selecting newtechnologies to draw up product architectures and diminish risks for

commercial application--also precedes Product Development and might beseen as an instantiation of Pages Concept Testing phase. Research, pre-development, and Product Development are also recognized as alternatephases in commercial Research & Development by Boersma (1994),Burgelman et al. (1988), and Freeman (1974). Research and pre-developmentcan be executed parallel to Product Development, but ProductDevelopment should not be dependent on their outcome to be controllable


41/259

Chapter 2

13

(Siskens, 1996). Table 2.1 illustrates the characteristics of the aforementioned phases to illustrate their differences, based on Boersma (1994).

Table 2.1 - Research & Development Phases Compared

Phase Process Result

Research Initiate Knowledge

Pre-Development Select Feasibility

Product Development Realize New Product Specification

In conclusion, some attention needs to be paid to the environmentsurrounding Product Development. Hales (1991) illustrates this in hiscomprehensive context model. In this context model, Product Development

(design in terms of Hales) and production are the core processes. For theseprocesses the major activities and outputs are indicated. Figure 2.1 positionsthese activities within the project, which provides the Product Developmenttask. The project is initiated by management posting the requirements in aproject brief, containing the major objectives pursued. Managementarranges the involvement of the companys financial and human resourcesand involves marketing, research & development, engineering, purchasing,quality assurance and customer service in the project. In Hales context,engineering is the major discipline involved in Product Development.

The goal of the project is to improve or maintain the competitive positionfor the company in the market by meeting market demands. The customeris the part of the market that actually buys and uses the product developedby means of the sales capability. The customer thus generates revenues forthe company. The number of customers determines the market share andprovides part of the feedback for future user needs. When a new demand isidentified the company can re-engage in the Product Development cycle.This demand may be also be triggered by external influences.

The remaining part of the model shows the resources the company retrievesfrom its environment in terms of funding, personnel, market information,technologies, materials and energy. Obsolete customer products arereturned to the environment. Parts of these can be reused and are added tothe environmental resources, the remainder is waste. The companysaccounts department might have to reimburse the government for the wastecreated by the product.


42/259


43/259

Chapter 2

15

2.3. Design Methodology

Design methodology provides insight into the way in which ProductDevelopment is performed. Finkelstein and Finkelstein (1983) present areview of design methodology. According to their definition, design

methodology...provides a useful framework for the structuring of the design process,generation of design concepts and for evaluation in design.

Next to this framework covering all or most activities in ProductDevelopment, several methods exist that basically support developers inone or more activities. Examples of these methods are Quality FunctionDeployment, Failure Mode and Effect Analysis, and Taguchi methods.Short descriptions of these methods are given by Pugh (1991). Furthermore,tools are developed that assist developers in making the right decisions forlater life-cycle stages. Design for Assembly is probably the most developed

tool in this field, but other Design for X tools are being used at present(Boothroyd et al., 1994).

Information Technology is often applied to support Product Developmentactivities. Especially the design of complex products has become dependenton these tools. Computer Aided Design and Computer Aided Engineeringare the most dominant tools here (Lei and Goldhar, 1990). New tools suchas Product Data Management and Communication Infrastructures are,however, becoming more important in handling the huge amounts of datain Product Development (Griffiths, 1995).

The aim of this section is to provide insight into the activities and

management of Product Development. Therefore, these point solutions willnot be considered in more detail. This review of design methodology iscertainly not as complete as Cross (1989) or Erens (1996), but discusses threemeaningful classes of design models:

1. Descriptive models that simply picture the sequences of activities forsolving Product Development problems in terms of underlyingmechanisms.

2. Prescriptive models that characterize a defined set of ProductDevelopment activities in an appropriate pattern.

3. Management models that focus on controlling Product Developmentactivities.

Descriptive Models

Case studies on how Product Development is executed are the basis fordescriptive models. Processes, strategies and problems-solving techniquesused by designers are presented. Finger and Dixon (1989) have revieweddescriptive models for design and conclude that a unified theory for such


44/259

Product Development

16

models cannot be presented. However, 5 mechanisms that are used can begenerally presented (Erens, 1996):

1. Problem formulation: The process of defining design goals in terms of awell-described problem statement, a list of possible solutions, and criteria

for the evaluation of these solutions.2. Problem decomposition: The process of decomposing the problem into

sub-problems that can be addressed separately to reduce the complexityof the problem.

3. Solution search and exploration: The process of formulating possiblesolutions to the (elements of a) design problem, by exploring severalsolution areas and selecting possible solution principles from these areas.

4. Solution evaluation and selection: the process of evaluating the chosensolution principles with the criteria of step 1 and selecting the solutionthat satisfies the criteria to the maximum extent.

5. Solution composition: the process of composing the solution for the sub-problems to check whether the chosen solutions meet the original designgoals.

Next to these general steps, the design process model by French (1985) isfrequently suggested for describing the activities that are typical ofconventional design. Figure 2.2 illustrates this model. The major drawbackof descriptive models is that they suggest the design process is heuristic,which cannot provide a guaranteed success when used.

Figure 2.2 - French's Descriptive Design Process Model

Prescriptive Models

Prescriptive models mainly focus on procedures and strategies forexecuting the design process. Many descriptive models stem frommechanical engineering, but are also used in other disciplines. These modelssuggest a systematic approach with general working stages all withmeasurable results. Such approaches can provide a logical, visible,transparent and comprehensible design process. The German Society ofEngineers (VDI) has developed a standard design process based on a

Need DetailingWorking

Drawing,

etc.

Analysis of

Problem

Statement

of Problem

Conceptual

Design

Selected

Schemes

Embodiment

of Schemes

Feedback


45/259

Chapter 2

17

comprehensive review. This VDI standard prescribes seven sequentialphases for the design of a single product:

1. Clarification of the task: the process of gathering information consideringthe requirements and constraints for the design task, resulting in a

specification.2. Determination of functions and their structures: the process of

establishing a function structure, searching for solution principles, andthen mapping the functions to solution principles, resulting in a functionstructure.

3. Search for solution principles and their combinations: the process ofdetermining which function principles can serve the functions specifiedand selecting those that jointly present the optimal solution for thespecified functions, resulting in principle solutions.

4. Division into realizable modules: the process of dividing the solutionprinciples into physically realizable modules, which are interconnected,resulting in a module structure.

5. Development of layouts and key-modules: the process of engineering thesolution principles, starting with the key modules, resulting inpreliminary layouts.

6. Completion of the overall layout: the process of completing the layoutsfor all modules, with attention for the structure of the complete product,resulting in a final layout.

7. Preparation for production and operating instructions: the process of

finalizing instructions for the modules to obey the manufacturingrestrictions, resulting in a product description.

Pahl and Beitz (1984) are often referred to for their model of engineeringdesign. Figure 2.3 illustrates their conception of the steps that should betaken in the Engineering Design process. These steps are in line with thesteps provided by the VDI standard, but include four major phases(clarification of the task, conceptual design, embodiment design and detaildesign). During the early phases the emphasis should be on optimizing theprinciple solution. Later phases should emphasize the optimization oflayouts and forms. Furthermore, the engineering design model indicates

that the intermediate design results are reviewed for further improvement,and that insights developed during the design can be used for adapting thespecification, if necessary.


46/259

Product Development

18

Figure 2.3 - Pahl & Beitzs Prescriptive Design Process Model

Management Models

Management models provide focal points for Product Developmentmanagers. Andreasen and Hein (1987) link managing and executingProduct Development activities in their Integrated Product Developmentmodel. According to this model, managers should define a strategy beforeProduct Development starts. This strategy should then be deployed in a

Task

Clarify the taskElaborate the specification

Identify essential problemsEstablish function structures

Search for solution princinples

Combine and firm up into concept variants

Evaluate against technical and ecenomic criteria

Develop preliminary layouts and form designs

Select best preliminary layoutsRefine and evaluate against technical and economic criteria

Preliminary layout

Concept

Specification

Optimize and complete form designs

Check errors and cost effectivenessPrepare the preliminary parts lists and production documents

Definitive layout

Finalise detailsComplete detail drawings and production documents

Check all documents

Documentation

Solution

Cla

rification

of

thetask

Conceptualdesign

Embodimentdesign

Detaildesign

Optimizationoftheprinciple

Optimizationofthelayoutandforms

Upgradeandimprove

Information:adaptthesepcification


47/259

Chapter 2

19

business search to identify the need for a new or improved product. Inparallel, Marketing defines the basic need, Product Development definesthe product type, and Process Development determines the basicproduction process. Based on the results of these processes, a formal

Product Development procedure is started, where the quality ofintermediate outputs is closely monitored by management. When theProduct Development nears completion, management supervises theintroduction process of the new product. These management activities areclosely coordinated, to make sure the product under development meets theneeds of the market. Figure 2.4 illustrates this model for managing ProductDevelopment.

Figure 2.4 - Andreasen & Heins Integrated Product Development &

Management Model

Ulrich and Eppinger (1995) accentuate managements role in ProductDevelopment project management. Four basic roles are presented:

1. Understanding and representing tasks: tasks are linked byinterdependencies. These interdependencies define whether tasks aresequential, parallel (executable at the same time) or coupled (iterative).The Design Structure Matrix, GANTT charts, PERT charts are used torepresent dependencies and timing.

2. Baseline project planning: the baseline plan consists of a project task list, aproject schedule, team staffing and organization requirements, a projectbudget and a project risk assessment.

Coordination

Determinationof Strategy

BusinessSearch

Follow-up ofProduct Development

Supervision

Product

principle

design

Preliminary

product

design

Modification

for

Manufacture

Product

Adaptation

TheNeed

Determining

the basic

need

User

investigation

Market

investigation

Preparation

for salesSales

Consideration

of process

type

Determining

type of

production

Determining

production

principles

Preparation

for

production

Production

ObjectivesPolicy