Design of product development systems

Show preview

Hide preview

Design of Product Development Systems by
Adrian Aguirre Granados Submitted to the System Design and Management Program in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management
at the MA
Massachusetts Institute of Technology
February 2008
C 2008 Adrian Aguirre Granados All rights reserved
ARCHIVES
SSACHUSETTS INSTITUTE OF TECHNOLOGY
J UIBRAN 03 2009
LIBRARIES
The author hereby grants to MIT permission to reproduce and to distribute publicly paper and electronic copies of this thesis document in whole or in part.
Signature of Author Adrian Aguirre Granados
System Design and Management Program February 2008
/") /1- .( R Certified and accepted by 6 )- -Patrick Hale
Senior Lecturer, Engineering Systems Division Thesis Supervisor
Executive Director System Design and Management Program
/"* n -- A

THIS PAGE INTENTIONALLY LEFT BLANK

To my Mother.
My source of inspiration, energy and strength. My Heroine.

Design of Product Development Systems by
Adrian Aguirre Granados Submitted to the Systems Design and Management Program In Partial Fulfillment of the Requirements for the Degree of
Master of Science in Engineering and Management ABSTRACT
The development of successful new products in less time and using fewer resources is key to the financial success of most consumer product companies. In this thesis we have studied the development of new products and how to systematically improve the execution of new product development. Product development is an activity that concerns multiple functions, involves technical complexity, a variety of stakeholders and is ultimately a complex human activity. We have used a systems engineering approach to tackle this complexity and study product development in a holistic manner. Consequently we have focused on what we call the product development system which includes all the elements of structure (functional elements, links and arrangement) and the elements of character or concept (values, principles, operating style) that define a specific product development organization. The study of the product development system is done using examples from the automotive industry and an extensive review of knowledge from prior studies into product development. Five elements of structure - product, process, people, tools and goals - are reviewed to provide guidelines and insight to what combination of these elements is required to build a congruent structure for a product development system. Additionally, communication in product development and architectural lessons are analyzed to enable the selection of character elements for the design of a product development system.
Following the systems engineering approach, the design of product development systems is done by focusing on developing the architecture for the system. It is proposed that by designing the system architecture one can define how product development will be executed and find the greatest opportunities to significantly improve the delivery of new products. Using this approach makes context - geographic location, culture, organization, economy - key to the final system design. As a result, the proposal for an improved product development system has been executed by designing an architecture for a specific product development organization - Ford of Mexico. The architecture for the system contains some elements that are generic to any organization and others that are specific to the product development organization of Ford of Mexico. However, all of the concepts that were used to design the architecture of the Ford of Mexico product development system are found to be equally valuable to other product development organizations that intend to improve their execution of product development. Finally, we have documented the effect that developing and implementing the product development system has had for the Ford of Mexico Product Development Organization. This information provides insight toward the value of designing a product development system and helps us provide a set of next steps for further deployment of the proposed product development system architecture at Ford of Mexico.
Thesis Supervisor: Patrick Hale Title: Senior Lecturer, Engineering Systems Division; Executive Director System Design and Management Program

ACKNOWLEDGEMENTS
The subject of this thesis stems from a personal passion for engineering, design and cars. The opportunity to complete my masters degree thesis on this subject has been a dream come true and I am indebt to all the people that have contributed to enable this. It would be too much to enlist
every person that I would like to thank, but I would like to mention a few that come to mind as key while finishing this work.
My Mother, whom encouraged me to go further and trusted me.
My Father, whom I admire greatly and was with me all the way.
My Brother and Sister, who gave their unflinching support during the toughest times.
Paulina, who was patient, supportive and helped open new doors.
Pat Hale, whom I deeply respect and proved invaluable by providing guidance, freedom, knowledge and had the patience to help me to complete this work- I can not be grateful enough.
Takahiro Endo, who was instrumental by providing friendship, insight and an open mind.
John Grace, who's insightful questions and support provided wise counsel along the way.
Lorenz Hofmann, who's unmatched honesty and respect for people give a true north.
Marcos Perez, whom provided guidance throughout and who's passion and vision enabled this program to become a reality.
FoM PD team, of whom many have been behind the scenes working to make this a reality.
My SDMO6 cohort, who's friendship and spirit make sure I stay wide awake in life.
The FoM SDM07 and SDM08, for providing feedback and an incentive to continue this work.
Participating in the SDM program and attending MIT has opened my eyes to a whole new world; for this I thank everyone that has surrounded and supported me during this time. For me, this thesis has been an adventure, a challenge, a great learning opportunity and without doubt one of the best times ever. I walk away from this thesis and period with an even greater thirst for knowledge and challenges; now certain that this is but a starting point.
Last, but not least, thank you all for making life enjoyable - it is great. B.D.S.P.F.H.

THIS PAGE INTENTIONALLY LEFT BLANK

Table of Contents
List of Figures .......................................................................................................................... 12
List of Tables ....................................... .................................................................. ........ 14
,ist of Acronym s ...................................................................................................................... 15
1 Introduction ....................... ........................................................................................... 17
1.1 M otivation .................. ........... ...... .................. ................................................... 17
1.2 Product Development in the Automotive Industry Today.............................. 21
1.3 Developing Automobiles for the Needs of Tomorrow....................... ........ 23
1.4 Thesis Objective and Hypotheses ....................................... ....................... 25
1.5 Data Collection Methods and Sources ............................ ......................... 27
1.6 The Relationship between Product Development System and Product Development O rganization ................................................................................................................... 29
1.7 Thesis Organization............................................................................... 30
2 General Notions in Product Development.......................... ...... .................. 31
2.1 Product Development as Information Transformation................................ 34
2.2 Interactions with Product Development ....................................... 36
2.2.1 Manufacturing ........ ................................................ ...... 36
2.2.2 M arketing ..................... .. ......... ... ...... .. .................................... 37
2.2.3 Advanced Research and Development ........................... ....................... 37
2 .2 .4 Su p p lie rs ........................................... ......... ..... . ........... .............. . . ..... 3 8
2.3 Approaches to Modeling Product Development............................ ..... ....................... 38
2.4 Framework for Detailed Study of Product Development ............................................. 39
2.5 Overview of Principles in Product Development.................................. 41
2.6 Key Takeaways - Product Development............................ ........................ 43
3 Product Development in the Automotive Industry............................. ....... 46
3.1 General Description of Automotive Design and Engineering..................................... 46
3.2 The Product Development Process................................. ..... ....................... 48
3.2.1 Define Phase .................... ............................................... 49
3 .2 .2 D esig n P hase ........................................................................................... ................... 50
3 .2 .3 V alid atio n Phase ..................... .................................................................................. 52
3.2 .4 Lau nch Phase .................................................................................................. . . ..... . 53

3 .3 G lo b a liza tio n ............................................................................................................................... 5 3
3.4 Key Takeaways - Automotive Product Development ................................ 55
4. Communication in the Product Development Organization ..................................... 57
4.1 Technical Com m unication ........................ ................................................................................. 57
4.2 Internal Com m unication ............................................................... ...... 60
4.2.1 Interactions and Information Exchanges ...................... .. . ................... 61
4.2.2 Integration Team s...................................... ...................... ............ 62
4.2.3 Influence of Culture on Internal Communication....................... ..................... 63
4.3 External Communication............................. .............................................. 65
4.3.1 Spoke and Hub ........................................ ................. ............................ 65
4 .3.2 Peer-to-Peer ............................................................. 66
4.4 Communication Medium and Forums............................... ......................... 68
4.4.1 Meetings, Design Reviews and Informal Encounters ................................... 68
4.4.2 Media - Face to Face, Video Conferencing, Phone and Email ..................................... 70
4.5 Enabling Communication in Product Development ........................... ................... 72
4.5.1 Com m unication Assessm ent................................ ... ........................ ...................... 72
4.5.2 Im proving Com m unication ................................................. ............ ...... ................ ..... 74
4.6 Key Takeaways - Communication in Product Development...................................... 78
5 People and the Organization.......................................................................................82 5.1 Unique Aspects of the 'Organization' in Product Development.......................... ........ 83
5 .1.1 Su p p lie rs ..................... ............... .............. .. .... ... .................. . . ..... 84
5.1.2 G lobalized Product Developm ent ................................... ...... ...... ................. ......... 85
5.2 The Role of Leaders in Product Development .................................. ........... ....................... 86
5.2.1 Technical Project Leader: System Designer or Process Manager............................. . 86 5.2.2 Levers for O rganizational Change ................................. ................. .............. ........ 88
5.2.3 The Vision - A desired state ....................................... ....................... 90
5.3 The Individual - Building Block of the Organization ............................................................... 90
5.3.1 Hiring ....................................... ............... 91
5.3.2 Initial Development of People within the Organization ......................... ...................... 92
5.3.3 Talent Retention ......................... ........................ ........................................... 93
5.4 Designing the O rganization ........................................................................................... .... 94
5.4.1 Definition of the Organizational Structure ..................................... ................. 94
8

5.4.2 Culture definition and design ............................................................. 96
5.4.3 Core Competencies ......................................... ........... 99
5.5 Organizational Learning ............................................... ... . .... . ..... . ........................ 103
5.6 Key Takeaways - People and the Organization ........................................ 104
6 Product and Process ........................................ 108
6.1 Th e Prod uct .................................................................................... ... ... . ............................ 108
6.1.1 Define ......................................... .......... ........ ............. 110
6 .1.2 D esign and V alid atio n .......................... ................ .. ...................................................... 111
6.1.3 Launch and Implementation .......................... 113
6.1.4 Additional Product System Observations ........................................ 113
6.2 Process ........................... ............................................ .......................... 114
6.2.1 Product as the Result of Information Transformation ..................................... 118
6.2.2 Standardization and flexibility .................. .. ............. .................................... 119
6.2.3 Process Engineering ............................................... 119
6.3 Alignment of Product and Process .............................................. 121
6.4 Key Takeaways - Product and Process ................................ ...................... 123
7 Incentives and Enablers for Product Development................... 125
7.1 The Incentives - Goals ......................................... ......................................... 125
7.1.1 Goals, Metrics and Targets in Product Development ....................................................... 126
7.1.2 Using Goals to Modify Organizational Behaviors ......................................................... 128
7.2 Enablers - Tools .. ........................ .. ........... .............................................. 129
7.2.1 Prototypes as Learning Tools............................... ............ .... 131
7.3 Key Takeaways - Enablers and Incentives ....................... ........................................................ 132
8 Case Studies in Product Development ............................. 134
8.1 Alignment of Process Timing - Development of Program Derivatives ..................................... 135
8.2 Commonizing Tool Usage -Ordering Prototype Parts.......................... ................................. 138
8.3 Requirements Development - Global Market Needs................................. 140
8.4 Engineering to Manufacturing - Launching a New Vehicle............................... 142
8.5 Suppliers and Engineering - Emissions Requirements and Fuel ............................................... 144
8.6 System to Component Interfaces - A/C System Development ..................................... 151
8.7 Knowledge Linking and Innovation - Fuel Economy Improvements........................ 154
8.8 Key Takeaways - Case Studies in Automotive Product Development ................................... 156
9

9 Design of a Product Development System ..................................... 158
9.1 Rationalfor Creating a New Product Development System Architecture ............................. 159
9.2 Guide to the Architecture and Design of Complex Systems..................................................... 161
9.2.1 Architecture of Complex Systems............................ .................... ... 161
9.2.2 Character and Structure Elements of the Product Development System ..................... 162
9.3 Goal and Design Objectives of the Product Development System.............................. 163 9.4 Contextual Setting for the Product Development System............................. ........................ 165
9.5 Concept for the Product Development System ........................................ 167
9.6 Character Elements of the Product Development System ..................................................... 168
9.6.1 Excellence in Communication ......................................... 169
9.6.2 Flexible Capabilities ....... ........................................ 170
9.6.3 Nimble and Robust Decision Process .......................................... ... 172
9.6.4 Perfect Execution Mindset........................................... 174
9.7 Detailed Description of Elements of Form and Structure.......................... 176
9.7.1 Product ...................................... ............ ...................... 178
9.7.2 Process ........................... ....... ............... ...... .................... ............... 179
9.7.3 People ....... .... ..... .................................................... 180
9 .7 .4 T o o ls....................... ................................. ................................... ............ .... 18 2
9.7.5 Goals .................. .................... ............ .... ...................... 183
9.7.6 Interfaces Among the Elements of Form ..................................... 185
9.8 Architecture of the Product Development System ............................................................. 186
9.9 Key Takeaways - Product Development System Architecture............................................... 187
10 The Organizational Effects of Designing the Product Development System............... 189
10.1 New Approach to Project Team Setup .................. .... ......................................... 189 10.2 Redefined Organizational Strategy................................. 191
10.3 Strategic discussion amongst FoM Leadership ................................. 192
10.4 Emphasis on Solution of Systemic Problems ........................................... ............................... 194
10.5 Key Takeaways - Effects of the Product Development System ........................................ 195
:11 Next Steps for the Product Development System of Ford of Mexico......................... 196 11.1 From Architecture to Workable Areas ........................................ 197
11.2 Opportunities for Immediate Implementation of the PDS ........................................ 199
11.2.1 Systems Engineering Organization .......................... ................ 200
10

11.3 Charter for Evolution of the Product Development System ........................................ 202
11.4 Guidelines for Implementing and Evolving the PDS Architecture .................... 206
11.5 Key Takeaways - Implementing and Evolving the PDS..................................... 208
12 Conclusions ........................ ....................................................................................... 210
Bibliography ..................................................................... .. 217

List of Figures
FIGURE 1-1 CHANGES IN MARKET SHARE FOR THE US CAR MARKET SINCE 1965 (BBC - IN DEPTH, THE CAR INDUSTRY) ........... 21 FIGURE 1-2 GLOBALIZATION OF THE AUTOMOTIVE INDUSTRY, TOTAL GLOBAL MANUFACTURING SITES FOR GM AND TOYOTA
(MODIFIED FROM - BBC- IN DEPTH, THE CAR INDUSTRY)................................................ 22 FIGURE 1-3 PRODUCTIVITY NUMBERS IN HOURS PER CAR, FOR US AUTOMAKERS (MODIFIED FROM - BBC - IN DEPTH, THE CAR
IN D U ST RY ) ...................................................................................................................................................... 2 2 FIGURE 1-4 RESEARCH DATA SOURCES AND THESIS FLOW DIAGRAM .................................................................... 27
FIGURE 1-5 GENERAL THESIS LAYOUT ..................................................... 30
FIGURE 2-1 PRODUCT DEVELOPMENT SYSTEM MAJOR INTERFACES AND COMPONENTS................................... ... ........... 31
FIGURE 2-2- FEEDBACK LOOP RESULTING OF REDUCING PRODUCT DEVELOPMENT TIMES, THEME FROM (DEHOFF & LOEHR, 2007).33 FIGURE 2-3 INFORMATION TRANSFORMATION PROCESS, ADAPTED FROM (FINE & WHITNEY, 1996, P. 9) ................................ 34 FIGURE 2-4 INFORMATION TRANSFORMATION EXAMPLE, TAKING THE VOICE OF THE CUSTOMER INTO THE FINISHED PRODUCT........35
FIGURE 2-5 AREAS OF OPPORTUNITY FOR BETTER PRODUCT DEVELOPMENT DERIVED FROM PROCESS MODELING TECHNIQUES (SHOOK & ROTHER, 1998) (CRAWLEY, 2006)(EPPINGER, JANUARY 2001) ........................................... ....... 39
FIGURE 2-6 MATRIX FRAMEWORK - TIME AND STRUCTURE APPROACH TO DEVELOPING THE PRODUCT DEVELOPMENT SYSTEM ........ 40
FIGURE 3-1 GM AUTOMOTIVE PLATFORM STRATEGY (DE W ECK 0., 2006) ...................................... .......... 47 FIGURE 3-2 UNIBODY VEHICLE CONSTRUCTION (FORD FREESTYLE BODY) .............................................. 47 FIGURE 3-3 COMPONENTS OF THE DEFINE STAGE AND THEIR OUTCOME (EXTENSIVELY ADAPTED FROM (CRAWLEY, 2006))...........50 FIGURE 3-4 COMPONENTS OF THE DESIGN STAGE AND THEIR OUTCOME (EXTENSIVELY ADAPTED FROM (CRAWLEY, 2006))...........51 FIGURE 3-5 COMPONENTS OF THE VALIDATE STAGE AND THEIR OUTCOME (EXTENSIVELY ADAPTED FROM (CRAWLEY, 2006))........52 FIGURE 3-6 COMPONENTS OF THE LAUNCH STAGE AND THEIR OUTCOME (EXTENSIVELY ADAPTED FROM (CRAWLEY, 2006))..........53 FIGURE 4-1 CULTURAL ASPECTS THAT INFLUENCE INTERNAL COMMUNICATION BETWEEN DIFFERENT GEOGRAPHIC LOCATIONS........64
FIGURE 4-2 USING THE DESIGN STRUCTURE MATRIX TO IDENTIFY COMMUNICATION PROBLEMS (SOSA, EPPINGER, & ROWLES, 2007)
FIGURE 4-3 AWARENESS SHEET OF THE COMMUNICATION GRID (MAIER, ECKERT, & CLARKSON, 2006) ................................... 74 FIGURE 4-4 PROJECT PERFORMANCE AS A FUNCTION OF TEAM TENURE (ALLEN T. J., 2006)...................... ...................... 77 FIGURE 5-1 LEVERS AND TOOLS FOR LEADING ORGANIZATIONS........... ........................................ 88
FIGURE 5-2 ROLES AND RESPONSIBILITIES ................................................................................... .................................. 89 FIGURE 5-3 LINK OF INDIVIDUAL ACTIONS TO ORGANIZATIONAL RESULTS ...................................................... 91
FIGURE 5-4 ENGINE MOUNTS AND ISSUE DESCRIPTION FOR FUTURE MODEL SUV............................................... 100
FIGURE 6-1BASIC KINDS OF DEPENDENCIES (MALONE, CROWSTON, & PENTLAND, 1999) ....................... ....................... 115 FIGURE 8-1 HISTORICAL DIESEL EMISSIONS STANDARDS PROGRESSION THROUGH 2010 (DETROIT DIESEL) ............................... 45 FIGURE 8-2 GENERIC DIESEL EXHAUST SYSTEM LAYOUT WITH A CATALYST AND DPF (FLOW GRID CONSORTIUM) .................... 1...46 FIGURE 9-1 VALUE CREATION STEP AND TRANSFORMATIONS AT EACH INTERFACE.................................... ......... 159
FIGURE 9-2 STEPS TOWARD ARCHITECTING A COMPLEX SYSTEM, MODIFIED FROM (CRAWLEY, 2006) ................................... 161 FIGURE 9-3 THREE LEVELS OF THE SPECIFIC SYSTEM CHARACTERISTICS THAT ARE SELECTED FOR DEFINITION OF SYSTEM REQUIREMENTS
.............................................................. ................................................ 165
FIGURE 9-4 CONCEPT FOR THE PDS, MAPPING THE SYSTEMS FUNCTION TO FORM ................................................................ 167 FIGURE 9-5 CHARACTER DIMENSIONS FOR THE PRODUCT DEVELOPMENT SYSTEM............................................ 168 FIGURE 9-6 CHARACTER ELEMENT: EXCELLENCE IN COMMUNICATION...........................................170 FIGURE 9-7 CHARACTER ELEMENT: FLEXIBLE CAPABILITIES .................................................................... .................... 171 FIGURE 9-8 CHARACTER ELEMENT: NIMBLE AND ROBUST DECISION PROCESS .................................................... 73 FIGURE 9-9 CHARACTER ELEMENT- PERFECT EXECUTION MINDSET ...................................................... 175
FIGURE 9-10 PRODUCT DEVELOPMENT SYSTEM STRUCTURE WITH CONCEPTUAL REPRESENTATION OF ARCHITECTURAL LEVELS ...... 176

FIGURE 9-11 INTERFACES AMONGST ELEMENTS OF STRUCTURE ..................................................... 177
FIGURE 9-12 STRUCTURE ELEMENT- PRODUCT .......................................... ................. 179
FIGURE 9-13 STRUCTURE ELEMENT - PROCESS ..................... ...................... ................. 180
FIGURE 9-14 STRUCTURE ELEM ENT- PEOPLE ................................................................ 181 FIGURE 9-15 STRUCTURE ELEMENT - TOOLS............................................... ................. 183
FIGURE 9-16 ELEMENT OF STRUCTURE - GOALS........................... ..................................... ................ 184
FIGURE 9-17 PD S A RCHITECTURE D IAGRAM ................................................................................................................ 186 FIGURE 11-1 IMPLEMENTATION DIAGRAM FOR THE PDS ARCHITECTURE .............................................. 196 FIGURE 11-2 EVOLUTION OF WORK AREAS ........................................... ................. 198
FIGURE 11-3 CONCEPT FOR IMPLEMENTATION ACTION PROCESS .................................................. 200 FIGURE 11-4 GENERAL FoM-MIT/SDM PDS ARCHITECTURE EVOLUTION PLAN USING THESIS ........................................... 202 FIGURE 11-5 ROLE OF THESIS IN GENERATING EVOLUTION OF THE PDS ARCHITECTURE ....................... .............. 203 FIGURE 11-6 DESIGNATED PHASES FOR THESES DEVELOPMENT ....................................................... 204

List of Tables
TABLE 4-1 SUMMARY OF COMMUNICATION INTERACTIONS. MODIFIED FROM (GRIFFIN & HAUSER, 1992) & (KATZ, 1982).........61 TABLE 8-1 EPA 2007 HEAVY DUTY TRUCK DIESEL EMISSIONS STANDARDS (DIESELNET) ..................................... 144 TABLE 8-2 SUMMARY OF SYSTEM DESIGN CONSIDERATIONS FOR DESIGNING THE PRODUCT DEVELOPMENT SYSTEM ................. 157
TABLE 9-1 VITAL DESIGN REQUIREMENTS FOR THE ARCHITECTURE OF THE PDS ............................................ 163 TABLE 9-2 DESIGN OBJECTIVES FOR THE FoM PDS BY STAKEHOLDER ............................... ........ .................... 164 TABLE 9-3 CONTEXTUAL ASPECTS OF THE FoM PDO FOR THE DESIGN OF A PDS ........................................ ................... 166 TABLE 11-1 WORK AREAS TO CONCEPT AND FORM MAP ......................... .......................................... 197
TABLE 11-2 GUIDELINES AND OPPORTUNITIES FOR WORK AREAS .................................................. 199 TABLE 11-3 INITIAL LIST OF POSSIBLE TOPIC AREAS FOR FUTURE THESES ......................... . ..................... 204 TABLE 11-4 ALIGNMENT ELEMENTS FOR FUTURE THESES ............................... .......................... 205 TABLE 11-5 GUIDELINES FOR SUCCESSFUL ORGANIZATIONAL CHANGE PROGRAMS (MODIFIED FORM (SHAPIRO, FALL 1984)).......206 TABLE 11-6 GUIDELINES FOR SUCCESSFUL DEPLOYMENT OF ORGANIZATIONAL CHANGE (MODIFIED FORM (DEHOFF & LOEHR,
INNOVATION AGILITY, 2007)) ..................................... ............................. ............ 207 TABLE 11-7 GUIDELINES FOR SUCCESSFUL ORGANIZATIONAL CHANGE ACTIONS (EXTENSIVELY MODIFIED FORM (BROWNING, FRICKE,
& N EGELE, 2006)).. . ....................................................................................................... ...... ................... 208 TABLE 11-8 THREE LEVELS OF ORGANIZATIONAL CHANGE.............................................. 209 TABLE 12-1 KEY DETERMINANTS FOR EACH OF THE STRUCTURAL ELEMENTS OF THE PRODUCT DEVELOPMENT SYSTEM .............. 211

List of Acronyms
Acronym Description A/C Air Conditioning A/T Automatic Transmission AOPM Architectural Object Process Methodology DSM Design Structure Matrix FoM North American Car of Mexico GPDS Global Product Development System LPDS Learning Product Development System LS Learning System NAC North American Car NOx Nitrous Oxides OEM Original Equipment Manufacturer OPM Object Process Methodology PDO Product Development Organization PDP Product Development Process PDS Product Development System PM Particulate Matter QFD Quality Function Deployment SE Systems Engineering VSM Value Stream Mapping WTP Willingness to Pay

THIS PAGE INTENTIONALLY LEFT BLANK

1 Introduction
The development of successful new products is today of concern to most consumer product
companies around the world. Pressure from the competition, increasingly sophisticated consumer expectations and a shifting environment make continual reinvention a necessity for companies wishing to remain competitive. Developing new products that are successful in these changing conditions is a complex task and one for which there is not a single best answer. What is clear, however, is that new products have a profound influence on the performance of their companies and that therefore the ability to improve product development becomes a competitive advantage. This thesis focuses on improving new product development and does so by using a systems engineering approach to the problem. Using this approach, the design of a product development system (PDS) is presented and then applied to improving an automotive Product Development Organization (PDO).
11.1 Motivation
Four years of work in the automotive industry have allowed me to participate in a variety of product development projects. In each project many engineering issues have arisen and fortunately the teams I have participated with have managed to find good solutions in all cases. However, even with the success in each case, when these projects are examined more closely, questions surface regarding whether the problems would have been easier to solve with a better process or if the problem should have ever occurred under other, better, circumstances. When reflecting on these questions, there was one particular case that stood out and truly captured the essence of the development problems I have encountered. This case is presented in the following paragraphs.
In automotive companies introduction of new materials to different vehicle components and subsystems is one of routine ways to improve the performance of a system, by reducing weight, improving performance and/or reducing cost. One would expect, therefore, that materials of overall improved physical properties and cost would quickly make their way into production. However, this is not always the case.
Automobiles today are made from sheet metal, and because of this, are subject to a variety of vibration-related problems. At the same time, the sheet metal constitutes the first barrier between a car's exterior environment and interior, providing insulation from weather, wind and noise. To enhance the capacity of sheet metal to act as a barrier to noise, and to avoid the nearly flat panels of sheet metal from exhibiting a drumming effect, a common solution is to apply mastic. Mastic is the generic name for a material that will be adhered to sheet metal in a thick layer (~6- 8mm) to increase the stiffness, energy absorption and sound isolation properties of sheet metal. In changing these characteristics of the sheet metal, mastic provides

an improved sound insulation barrier and reduces the sheet metals drumming effect by means of increasing its energy dissipation capacity.
In automotive product development there is a need to improve the noise levels inside a vehicle's cabin, and therefore NVH (noise vibration and harshness) engineers work to achieve this. Left to their own devices, NVH engineers might choose to use huge amounts of mastic to reduce as much of the noise and vibration possible. However, in designing a vehicle there are also cost and weight considerations associated with increasing mastic usage and it is therefore necessary to work on optimizing mastic use. The work to optimize the use of mastic is done routinely in the development of new automobiles, and should therefore be a well understood problem.
During the development of a new vehicle, I had the opportunity to experience this problem. It was, however, fortunate that in working to solve this problem an opportunity to evaluate a 'new' material arose. The material in question had been proven to have increased the laboratory performance in comparison to the current production material, and experienced NVH engineers agreed that significant improvements in vehicle NVH could be obtained by using the new material. A test with the new material was conducted on a prototype vehicle, obtaining successful results, but resistance to use the material in production developed due to material cost.
Vehicle cost is a critical item in today's hyper competitive automotive industry, and it therefore made sense to avoid using a more expensive material. The purchasing department was in charge of material cost for the mastic, and two years of conversations between engineering, suppliers and purchasing had made little progress towards getting the material into production. Analysis of why the material had not yet made it into production revealed a few key variables on which the decision pended.
* Cost per pound of mastic * Application method * Material toxicity * Supplier approval
Initial conversations regarding the use of the material quickly revealed that there was a great disparity in the languages spoken by the purchasing and engineering departments. In reality, application and toxicity had been proven to be a non-issue, but purchasing had not been given the right document and therefore always came back to these items upon beginning a conversation. The approval of the supplier, although not trivial, also came out to be a smaller problem that thought. Only cost was left as a true barrier that seemed to have no resolution.

Cost estimates for the new material were received by purchasing as dollars per pound of mastic, and under this evaluation the new material always came up negatively. To persuade purchasing to agree on buying the new material engineering presented lengthy technical analysis of the advantages of using this new material citing test result numbers and effects on customer satisfaction. This discussion made little progress and went back and forth for months.
It was not until the problem was reanalyzed in a different light that progress was made. The cost metric being used by purchasing was found to be inadequate for this problem; materials with different performance benefits per pound were being compared solely on their cost per pound. A combination of metrics provided a comparison of cost per unit of performance and quickly showed that the 'new & expensive' material was, in reality, cheaper to use when targeting the same vehicle performance. Additionally, the team could also take a few pounds off the finished car without impacting interior cabin quietness.
In retrospect, the process of getting to this conclusion and enabling the team to move one step closer to implementation of the mastic should have taken days, not months.
Looking back at this example, it is exasperating to realize that resolving this issue should have been second nature to the engineering and purchasing teams, but it wasn't. The process, IT tools, goals, organizational structure and culture should have come together enabling the team to arrive at a solution quicker. In other words, the product development system in this example should have never allowed this problem to exist. This begs a first key question: can we remove systemic problems in product development and find a way to create a world class product development organization?
Developing the next automobile, plane, operating system or any other complex product requires
product development organizations to go through thousands of situations similar to the one presented - activities that require carefully orchestrated multidisciplinary teams to resolve tensions between cost and performance and make the right decisions developing new products. The strategic importance of new product development, the complexity of the developing new products and the many instances where similar situations occur start making this first question truly critical.
In context, this question acquires a new dimension and its full importance is apparent. I have been fortunate that, coincident with my normal engineering activities, I have been involved in, a second, and very relevant product development situation. The thirty something year old Product [)evelopment Organization of Ford of Mexico (FoM) received instructions to increase its ability to support the NAC (North America Car) global product development effort. This meant that the FoM Product Development Organization (PDO) was being asked to extend its engineering and product development capabilities, but little direction was being given as to how this could be best achieved. FoM therefore needed to create a growth plan that would allow them to acquire the requisite

product development abilities to make it an effective support element to the Global Product Development Organization of NAC. This need presented a great challenge, and an even larger opportunity, to redefine what product development is by starting product development (PD) from a clean sheet of paper. Capitalizing on this opportunity led to a second key question: where and how does one start creating a better product development organization?
This author was part of the engineering team challenged with creating the new PDO, giving these questions vital importance. This fact became an important element of the motivation for the thesis. Early in the process, it became apparent that the challenges leading to improving product development were without doubt larger than what could be covered in a single thesis. Acknowledging this fundamental problem leads to a third question that shapes this thesis.
Ford of Mexico began an effort to acquire systems thinking capability and provide the best available development opportunities for high potential engineers. Participation in the MIT Systems Design and Management program is a result of this and frames a third question. This thesis is the first in a series of theses which are part of the larger effort of Ford of Mexico to acquire systems thinking capability. Work on each thesis could well be on excellent yet separate topics, but they could also be brought together to work on a single, larger problem. Therefore the third key question became: can we create a framework and master plan to allow the aggregate effort of multiple theses at MIT to align and work toward creating a better product development organization?
These future theses could represent an opportunity for FoM to review in detail all of the issues pending to develop a better PDO. However, there was also a real danger that by using multiple theses we could diverge in focus and lose a unique opportunity. These considerations lead us to believe that there is much to gain by creating a conceptual framework that provides the cohesive foundation for multiple individual theses. Together these theses could systematically improve product development by working within the whole product development system. Correctly implemented, each individual thesis could solve a different issue, such as the underlying causes of the mastic example presented, and contribute toward a new and better product development system. Achieving this requires generating the links and common structure that allows several individual theses to work toward a single objective, and a master plan for the future product development system of FoM.
Today our motivation to seek a better product development system has become even stronger. Finding new and improved solutions to people's needs through better products is a must in the context of diminishing natural resources and environmental issues. The automotive business is confronted with many opportunities to rise to the challenge and provide products that truly meet the needs of our clients - products that have a reduced carbon impact, use renewable energy and maybe even help us repair some of the damage that has been done to date. Developing new technologies and then integrating them into consumer products will overcome these challenges. Achieving these objectives requires product development organizations that are better at understanding the customer needs and can deliver increased added value by reducing time and cost to bring new technologies and products to the market.

This thesis therefore aims to work toward significantly improving product development, achieving
both general insights and specific improvements for the Ford of Mexico Product Development
organization. This intention is framed by the three questions described previously.
1. Can we remove systemic problems found in product development and find a way to create a
world class product development organization? 2. Where and how does one start creating a better product development organization?
3. Can we create a framework and master plan to allow the aggregate effort of multiple theses
at MIT to align and work toward creating a better product development organization?
1.2 Product Development in the Automotive Industry Today
Development of new cars is the cornerstone to the survival of companies involved in the
manufacturing and selling of automobiles. In no other industry is the speed and ability to bring new
high quality and high performance products to the market as evident a competitive advantage as
within the auto industry. Today, the existence of a true set of global players in the automotive
industry and the relentless surge of new products from all participants makes the industry one of
the fiercest in terms of competition in the world market place. The growth of new markets around
the world and increased specialization of the existing markets makes delivering products to meet all
customer needs an increasingly complex task. Most leaders of global automotive manufacturers
agree that their companies' ability to develop the next generation of cars that will be the single most
important factor in their success or failure.
The automotive industry continues to be an essential part of the world's economy. In the United
States alone, the automotive industry represented the 3.2% of the GDP in 2002 (McAliden, Hill, & Swiecki, Fall 2003, p. 6). Development of new automobiles is therefore critical to both company survival and general economic health due to its net contribution and the jobs it creates.
1965 1985 Japan, 2005Japan, 2% 20% Europe, 8% Japan,
Europe, 5% 43% US, 52%
US, 90% Europe, 5%
Figure 1-1 Changes in market share for the US car market since 1965 (BBC - In Depth, The Car Industry)
The automotive industry in the United States is today at a point where almost half of the vehicles
sold are produced by non-US manufacturers [Figure 1-1]. This demonstrates the heightened competition in global markets, and the difficulties that new products face when entering this hyper
competitive market place. In particular Japanese automakers have taken a large piece of what used
to be the sales of US automakers, driven for the most part by their ability to deliver a better value

proposition. How Japanese automakers create a better value proposition has been a topic of much
discussion amongst academic and industry leaders with little true consensus to this date. All do
however conclude that the ability of the Japanese - Toyota, Honda - to deliver improved value to
their customers is intimately linked to their ability to integrate and align the organizations to
conceive, design and manufacture products that deliver high value to the customer.
i0-
S
: 9
S I-
0i *0
*
~9 9iP
0
i .-. p
0 - ~ : S..,
0
2005
Figure 1-2 Globalization of the automotive industry, total global manufacturing sites for GM and Toyota (Modified from - BBC - In Depth, The Car Industry)
In addition to the increasingly competitive landscape in the United States, the overall market for
automobiles is today larger than ever before. As shown in Figure 1-2, in the past 50 years the
manufacturing of automobiles has gone from being a largely centralized activity to being distributed
around the world. This is a consequence of market pressures to reduce cost, and also of the
increased number of markets that buy cars in sufficient quantities to merit production facilities.
With increased sales volumes in around the globe, OEMs (original equipment manufacturers) must capture customer needs for each market, and grow product development capabilities to design
products that meet these many needs. This situation requires that global automotive companies
meet the conflicting goals of developing vehicles suited to the needs of each market and maximizing
the commonality amongst vehicles to remain competitive in the marketplace.
50
45 ° -- Chrysler
40 ......... GM
"Mso- - - Ford
35 ***.... - Honda
- - - Nissan 30 .....
- - ,,. Toyota
25 1 1998 1999 2000 2001 2002 2003 2004 2005
Figure 1-3 Productivity numbers in hours per car, for US automakers (Modified from - BBC - In Depth, The Car Industry)
-1

Product cost is a key element in a company's competitive advantage as it increases the profit margin for all of a companies operation. In the automotive industry, the amount of time it takes to build a car has been shown to be a good indicator of the overall manufacturing cost efficiency of the company. In Figure 1-3 the average number of hours it takes different automakers to produce a vehicle on is shown. As we can see, since 1998 Japanese automakers - Honda, Nissan, Toyota - have consistently had lower manufacturing times. Although better manufacturing times are partly a matter of manufacturing operations, they are also a consequence of how the product was designed. Design for manufacturability has been one of the maxims for Toyota, and by developing products with this philosophy they have acquired a significant competitive advantage. At the root of this advantage is a better understanding of product development and how it helps a company create value.
The automotive industry is highly competitive, and presents numerous challenges for the OEMs. A myriad of different markets, changing usage conditions, global economies, manufacturing by the millions and other global challenges add up to make the present situation of product development in the automotive industry one of the most challenging and interesting ever. The opportunity for change and improvement this presents is therefore one of the largest the automotive industry has ever seen.
1.3 Developing Automobiles for the Needs of Tomorrow
The world today faces an increasing number of global challenges that cross the boundaries of nations and industries alike. Some of the most important ones include climate change, depletion of natural resources, population growth, shifting demographics, social inequality, urbanization and congestion (Ford Motor Company, Sustainability Report, 2006). All of these challenges have a profound impact on the automotive industry and provide enormous opportunities to those companies that can address these needs with great products. Integrating these opportunities into new products is not an easy task; especially because in many cases the needs and pressures of business today hinder us from working on what will be needed tomorrow.
Companies of all industries face pressures on a daily basis to deliver results and must achieve balance between short and long term goals. Both sets are necessary to enable a company's success, but each influences companies to move in different directions. On one hand, long term goals point towards sustainability and investing in new technologies that lessen our burden on the environment and society. On the other short term goals call for aggressive competitiveness to survive in the market. In this context product development has a critical to play role in enabling the integration of new technologies that address the world's challenges into manufacturable and marketable consumer products. Integration of both aspects must be achieved to help companies meet both long and short term goals.
Product development organizations must improve their ability to integrate new technologies to meet the many challenges we face. Amongst the challenges we must address, energy sources and

their usage top the list because of the profound impact they have on our environment and the tangible character of the problem. Since the beginning of the automotive era at the beginning of the 20 th century cars have relied primarily on oil based fuels as an energy source. The finite nature of oil reserves and the emissions of burning gasoline and diesel have prompted governments to regulate fuel usage by automobiles. Car companies have begun delivering in this regard, and one of the answers have been hybrid vehicles. This process, however, took much too long and companies that can begin integrating new technologies faster will be better positioned in the market.
Global pressures, changes in social and economic priorities and new customer needs push product development to evolve and improve. We have listed a series of elements we expect may help product development organizations meet the challenges of the future. The following list provides this vision of what we can expect a product development system to look like going into the future regarding both strategy and enablers.
ELEMENTS OF PRODUCT DEVELOPMENT STRATEGY
* Global development teams and product development strategies * Full modular designs with standard interfaces for all major systems and sub-systems * Quick integration of high impact global trends - energy sources, social movements,
environmental issues, etc - to engineering requirements * Increased interaction of research and development activities allowing for quick technology
transfer to the customer
ENABLERS OF FUTURE PRODUCT DEVELOPMENT
* Rapid die processes to eliminate one of the longest lead time items * Ultra-quick drawing-to-production turn around times, with low cost tooling and high
flexibility * Use of multi-material rapid prototyping machines, that can produce production ready parts
in minutes to aid in the development of many of the interior, ornamentation and non- structural elements of the vehicle
* Use of fully integrated virtual design tools that combine all elements of virtual analysis into a single database
* Integration of design rules, requirements and regulatory standards to virtual design tools to aid during the development process
* Improved customer need identification methods and tools * Comprehensive probabilistic decision analysis tools for selecting manufacturing facilities * Simplified product requirements database, that helps manage three items: customer
requirements, regulations and the vehicle platform requirements * Almost instantaneous project team setup capability, with real time knowledge of resource
availability and capacities

The list presented here goes through many different aspects of product development and makes educated guesses on what could happen in the future, yet the only thing that we can be certain of is that the product development systems evolution will be guided by our customers' needs.
The product development organization we intend to design will account for some of these problems. We will look to integrate a broader notion of what customer needs are by looking at all stakeholders, increase the competitiveness of the company by achieving better integration to advanced research and deliver world class products with the lowest cost and fastest delivery time in the industry.
1.4 Thesis Objective and Hypotheses As presented in Section 1.1, the motivation for this thesis comes from observations and experience within product development, the emerging need to grow product development for FoM (Ford of Mexico) and the latent opportunity to attack a large problem with the support of additional follow on theses. The objective for this thesis is therefore:
Thesis Objective: To design a successful product development system by conceiving and designing the system architecture and laying the foundations to enable future detail design work.
Automotive product development has been the subject of much study, in particular because of the measurable differences that exist in time and cost for the same activity among different OEMs. From the studies done to date, many guidelines, methods, best practices, principles and processes have been derived and in some cases applied effectively within companies. The application of this knowledge has helped OEMs reduce the cost of their product development activities and minimize their time-to-market with the intention of maximizing their market share and profit. As was described by Kenneth Sobek in his PhD dissertation (Sobek, 1997) even when these objectives and the tools available are the same, not all companies execute product development in the same manner or achieve the same end results.
Mastering the execution of product development to minimize the time and cost for a new car is a business advantage, but today there is still no one formula to achieve this. One of the problems that make finding a single formula difficult is revealed in reviewing available product development literature (Brown & Eisenhardt, 1995) (Krishnan & Ulrich, 2001) (Griffin & Hauser, 1992) (Watanabe, Thomas A. Stewart, & Raman, 2007) and is the impact of cultural differences on the execution of product development. Instead of alienating the culture from the improvement of product development in this thesis, we regard culture as a characteristic of the organization that can be defined and designed as an integral part of the system. This thesis proposes that the product development system can be improved to reduce time and cost while increasing product performance and quality; and that achieving this requires a holistic approach that is supported on integrating process, people, tools and goals.

With the thesis objective and motivations as background we have setup three hypotheses to guide the discussion in this thesis. They are the following:
Hypothesis 1: Product development can be considered a system, and can therefore also be designed as one
Hypothesis 2: Improving the architecture of the Product Development System can have a profound effect on the outcome of product development, in addition to improving the quality and potential of the people, the process, the tools or the product
Hypothesis 3: Design and implementation of an improved Product Development System can be accomplished by creating the architecture and then working semi-independently on complementary parts
Pursuing a redesign of the product development system starting from the architecture, we have considered the following two heuristics. First, introducing incremental improvements to the current product development activities yields small but consistent improvements in the performance of the system. Second, designing a system's basic architecture can yield gains on the order of 6-7 times better performance. Because of this, we support a method of combining systematic improvements to the current system and creating the opportunities for a breakthrough re-architecture of the system. This thesis has been provided opportunity for pursuing breakthroughs and will secure the foundations for further advancement in this regard.

1.5 Data Collection Methods and Sources
To meet the objective of this thesis and prove the hypothesis outlined in the previous section it was necessary to consult a variety of sources. The following figure presents a short summary.
................................... . ----------------------------------------------------------.........
- -- - - - - -- - -
- - - .. .. . .. . ..
. .. .. . .. . .. . ...
Information Sources Thesis Flow Purpose
FLeterature Reviewof the main form and function elements f PD
s r A nayis frea PDe issues and
Prac t Ice identificationof their
MIuhres
Synthesis of real world
swo a PS architecture for FoMdnforatio
Figure -4 Research data sources and thesis flowarchitecture for Fodiagram
The data collection methods and sources allow for comprehensive coverage of the existing academicfurther
knowledge, current industry practices and future product development teencies. Wen will use the
following paragraphs to describe some of the more important aspects of this research.of the PDS
The interviews conducted for the thesis were planned to bring breadth and depth to the subject ofanother and between countries; for example most agree that Japan and Germany excel aton
automotive engineering, and that product development practices of Toyota are different to those of
Sony. Therefore interviews and research trips were designed to provide access to the knowledge ofleaders in producat development that spanned different companiesic products and countries.InfoationFigureautomotive companies and the automotive rsouresearch center of the University of Aachen. BydiagramconThe data collctionng this researchods annd immensely valuablfor comprehe insightve coverage of how the existingeering andemicknowledge, current industry practices and future product development system of Germany was obtained. The insights from this trip are sprwill use thethrfollowing paragraphs to describe somthe whole of the morthesis and have impacted its conclusions; yet one aspects of thisat must beresearch.
product developmentioned is that the general conclusion thatfrom product development practices change from one company to as a
mentioned is that the general conclusion from product development in Germany is that as a

country, Germany, has a system that promotes top notch engineering all the way from academia and research and into high quality manufacturing of world class products.
In the United States many interviews were conducted with chief engineers and product development directors at two different companies. In addition to this, lectures and conferences by product development leaders as part of the System Design and Management program, rounded out the vision of product development in the United States. These interviews and lectures occurred over a span of two years, starting in 2006, and lead, in many cases, to follow up reviews and conversations. Through them, personal insights into the changes that product development has experienced over the past decades, and lessons in how to improve product development, were obtained.
Mexico was the third country that was included in the research. Knowledge of product development from Mexico is especially rich thanks to continual direct contact with high ranking product development leaders throughout the development of this thesis. These continual interactions allowed deeper understanding of the difficulties of growing a product development organization and also provided a unique opportunity to implement a few architectural changes to the organization while the research was taking place
In addition to this, a source that was used as inspiration for better and faster product development was the world of racing. Here, interviews with people involved with NASCAR and research into the world of WRC (the World Rally Championship) provided some of the most useful lessons to improve product development. Interestingly, many people that work in race teams have at some point also worked on engineering of consumer vehicles; as a result, an excellent critical review of the failures in automotive product development was obtained from this research.
The cases examples in product development came from the author's personal experience in product development. In some of these cases, initial efforts to apply systems engineering principles and thinking were attempted and demonstrated the benefits that can come from using a systematic approach to complex problems. These cases have been documented in this thesis and serve as support for some of the architectural decisions.
The information sources come together to allow the creation of the PDS (Product Development System) architecture for FoM (Ford of Mexico). The combination of real world examples, direct sources from different locations around the world and deep academic research provide some new insights to PD and help advance the understanding of this topic area.

1.6 The Relationship between Product Development System and Product Development Organization
Two distinct concepts have been used until now to describing the motivation and goals for this thesis, they are the Product Development System (PDS) and Product Development Organization (PDO). Understanding the difference between the two is conceptually important as they are discussed repeatedly throughout the thesis and are fundamental to the structure of this thesis. The definitions as used in this thesis are as follow:
* The Product Development System (PDS) is defined as all the elements, links and structure necessary to develop a new product. Within this system we have identified five main elements of form - product, process, people/organization, tools and goals (Browning, Fricke, & Negele, 2006) - that must all be present to develop a new product. In addition to this we also identified elements of character (Aguirre Esponda, 2008) and then used them both to create the architecture for the PDS. The PDS is for the most part abstract and works primarily with general concepts and high-level structures amongst all elements.
* The Product Development Organization (PDO) is defined as the entity that contains the aggregate of elements and resources within a company that is responsible of developing new products. The product development organization has all the same elements that are found in the PDS, but it include all the elements and nuances that come from implementation. The PDO includes the specific cultural, product, industry, economic, environmental and other factors that change direct how we implement.
The relationship between the Product Development System and the Product Development Organization can be summarized in the following sentence:
The Product Development Organization (PDO) is the embodiment of the Product Development System (PDS).
However, even with the definitions that we have provided, arriving at a single solid relationship between both elements, and thus allowing complete separation of both terms throughout the thesis, has not been possible. Their value for the thesis lies in using them as tools to enable rigorous analysis of product development. In practical terms they help us concentrate our analysis, research and design efforts mainly at the product development system (PDS) to generate an organized framework for product development; and then add clarity to the relationship between the concepts presented and the application of knowledge to improve and grow the FoM product development organization (PDO).

1.7 Thesis Organization
The goal of this thesis is to design an improved PDS (product development system). The structure of
chapters has been selected to provide a logical progression through the process of designing the
product development system. Figure 1-5 provides a high-level overview of the five larger sections of
the thesis and their associated chapters.
Thesis Flow
tCh. 1 Introduction
Ch.12 Conclusions and Future Work
Figure 1-5 General Thesis layout
In section one (chapters two through seven) a detailed review of product development is conducted going from the general to the particular. This section provides the necessary depth needed to
understand all the elements of the PDS and prepare the discussion for a well informed design for the
architecture the PDS of FoM. Section two (chapter eight) then focuses on presenting seven case studies in product development that identify some of the core systemic issues that hinder the
execution of better product development. With this information section three (chapter nine) develops an architecture for the product development system of FoM and provides guidelines for all
of the key elements. Section four (chapter 10) presents examples of the effects that the architecture has had up to date in Ford of Mexico, helping validate some of the assumptions made initially.
Finally in section five (chapter 11) we develop a plan to support the implementation and evolution of the PDS at FoM, providing the framework to allow future work on the PDS.

2 General Notions in Product Development
A high-level review of the essential aspects and trends that have been explored by other authors is
important to lay the foundation for the following chapters. A first important concept is that product
development is considered mainly as an information transformation activity. The consequences of
this insight are far reaching and set the tone for much of the work done. Previous work in product
development agrees with looking at product development in this light and enables us to provide
substantial support for our arguments.
A second concept critical concept is that product development must work extensively with other
functional areas to deliver new products. As an example, manufacturing is one of the main clients of
PD and as such imposes requirements and limitations on what can be done. These influences must
be known to improve our decision making and streamline the value chain. Good understanding of
the interfaces that product development has with other functional organizations is needed to create
value and identify areas of opportunity for improving product development.
Needs
Marketin
Product
I
-
I tiat an
! ervice
-- -
L
k~ffairs Su ations
rporate ice, HR, P I
Figure 2-1 Product development system major interfaces and components
Throughout this thesis we will explore both of the concepts described above and a large portion of
the space depicted in Figure 2-1. Focus will be on the product development system and the
interactions (arrows in the figure) with other organizations. By understanding the product development system and the relationships with other functional areas we can contextualize product
development and lay foundations for detailed analysis.
Re EniringmtMauatrnW4
I
I I
I
I - --- --------- '
I
% - - - - - --

In defining what product development is Ulrich and Eppinger provide a simple and straight forward approach.
A product is something sold by an enterprise to its customers. Product development is the set of activities beginning with the perception of a market opportunity and ending in the production, sale and delivery of product.(Ulrich, Karl T.; Eppinger, Steven D., 2004).
All companies involved in commercial activities strive to develop and manufacture products that meet the needs of their customers (Ogawa, 2006). For most companies it is their ability to deliver these products that determines their economic success or failure. The delivery of a new product covers a wide range of activities including: identifying the need, designing a product, manufacturing, sales and maintenance. Because of the span that exists between identifying a need and being able to manufacture a product, product development elicits the coordinated effort of multifunctional teams. To be effective these multifunctional teams must have the ability to perceive a need and transform it into a desirable product (Ulrich, Karl T.; Eppinger, Steven D., 2004). Leading these teams to deliver requires that we align process, people, tools and their incentives towards designing the new product.
Successful execution of product development depends greatly on our ability to plan and understand the scope of the task ahead. Many people and companies have worked on developing processes to improve our planning ability and reduce uncertainty. Although none of the processes are identical, most follow the same general approach. One of the high level approaches used within the automotive business divides the process into four sets of activities, and is for the purpose of this thesis a convenient way of looking at product development.
* Define - identify needs, translate into requirements and create a product concept * Design - development of detailed design to achieve an economically feasible solution * Validate - compare design against initial requirements for compliance * Launch - transfer of product from engineering to manufacturing, implementation
The central objective of this process is to transform the information obtained from the customer to a detailed design that can be manufactured and sold (Tatikonda & Rosenthal, 2000). For the greater part of the product development process the raw material for the sub-processes is information from its predecessor and its output is information that has suffered some degree of transformation. A process that is effective at managing information is therefore crucial if product development is to add value effectively.
Companies have spent a significant amount of resources developing detailed product development processes. The main goal of these processes is coordinating the sequence of activities needed to allow different functional organizations to communicate and coordinate at the right times. Some of the organizations involved include marketing, finance, legal affairs, sales and manufacturing. Having a good product development process enables these different functions to work in synchrony.

The product development process is also important to enable faster product development. Reducing
the time from concept to market introduction impacts both the ability to capture new markets and
the risk a company takes with each new product. 'Faster market feedback means less reliance on
long term guesses about customer preferences' (Dehoff & Loehr, Innovation Agility, 2007) - product development processes that reduce our time to market can as a consequence make a significant
difference in our ability to meet customer needs. In Figure 2-2 we conceptually show how faster
product development impacts our overall business.
Figure 2-2- Feedback loop resulting of reducing product development times, theme from (Dehoff & Loehr, 2007)
The process provides a mechanism to coordinate product development, but does little in regards to
actually getting the work done. Work is done by people, engineers for the most part, solving
problems using analytical and quantitative skills, in teams and individually. To accomplish their
tasks, engineers use tools to enable them to work better and more efficiently. These tools come
from many sources and are directed at a variety of problems, ranging from purely technical to social
and team interaction facilitation. The ability of a company to provide the best possible tools to the
employees and disseminate new ones allows for standardization and huge gains in efficiency. Gains
in efficiency increase the available time to engineer better product, boosting the potential of the
entire product development group.
The process of product development spans over many different organizations, but can be said to be
mainly concerned with three:
* Marketing * Manufacturing * Engineering
f

The coordinated work of these functions is critical to developing successful products. Differences in objectives, languages and internal cultures make this alignment an important task on the project leader. For many product development firms the epitome of the engineering project leader can be seen in Toyota with their extremely effective 'shusa' model (Liker, 2003).
Improving time to market, reducing risk, improving delivery of customer expectations, multifunctional work, bringing a product to manufacturing and preparing for sale are some of the activities that product development must work on. Achieving a healthy balance of cost, time and quality for all these activities distinguishes good product development systems and their processes.
2.1 Product Development as Information Transformation
'Design activities as information processors.' (Pahl & Beitz, 2007) 'The result of many product development activities is just information. Information is what flows; it is the life-blood of projects.' (Browning, Fricke, & Negele, 2006)
The working material of product development is information. On one side, customers have needs that are expressed verbally in an explicit manner or implicitly in their actions. At the other end of the development process, manufacturing must receive a set of detailed instructions on how to fabricate the product. As a whole system, product development leads the transformation of information to allow entities that speak different languages - the customer, manufacturing and others - to communicate.
Determine Customer
/ I Convert Needs to Engineering Specs
I I
Convert Engineering Specs to Detailed Design
I I I Verify tnat Design meets
I Specs
I Convert Detailed Design to I Process Specs I
I I Convert Process Spec to
Process Product Development
-------------------------------- , , , ,
Make Item
Figure 2-3 Information transformation process, adapted from (Fine & Whitney, 1996, p. 9)

The exchange of information lies at the center of what product development is (Eppinger, January 2001). The inputs and outputs of the different product development processes are information. In contrast to other functional areas all the added value of engineering resides in the ability to
effectively transform information across domains. Additionally product development also differs
from other activities, in that it requires innovation and the complex learning loops that are
associated with innovation (Eppinger, January 2001). Added value in the transformation of information and the need for innovation make understanding how information moves through
product development critical.
Product development concentrates on the activities required to take a product from customer
needs to finished products. Insights as to where some of the strengths and weaknesses inherent to
product development lie are possible when we analyze these activities as mainly information
transformation (Browning, Fricke, & Negele, 2006). As shown by Browning et al., there are many processes that information goes through to achieve the goal of developing a product. In each of
these changes, the information can be modified in unexpected and uncontrolled ways, posing a
significant problem for the system. Making sure that we can transform information between a
customer need and a finished product in a controlled manner enhances added value provided by
product development.
Voice of Customer Product Development Finished Product System
Good Information Transiormation
Bad information Transformation
Figure 2-4 Information transformation example, taking the voice of the customer into the finished product
Product development as information transformation is a model that has become true in both
concept and reality over the past two decades, with an almost universal disappearance of any
physical representation of information. What used to be a set of engineering drawings and
specifications on paper has now disappeared and been replaced with digital content. Therefore,
today more than ever the leaders of product development organizations must be cognizant of the
importance that information has within product development. For us, developing a product
development system that can transform the customer's voice and carry this information signal into a
finished product with a high fidelity is a must.

2.2 Interactions with Product Development
Within large organizations, functions have become highly specialized and different groups have been created to cope with the increased depth of knowledge in each area. Best practice indicates that product development should integrate other functions such as marketing and manufacturing as part of the core development team. However, within many companies it has been observed that instead of having seamless integration, the relationships are almost adversarial. Knowledge of the interfaces and good cross-functional work can help determine the success of a new product.
Organizations upstream and downstream from product development must be understood and integrated to increase the added value to customers. Integration must be such that all functional organizations are aligned toward maximizing the potential of a company to deliver successful products. Good knowledge of the whole value stream allows us to lean our operations and reduce development costs and time.
The next four subsections, present a short introduction to these organizational interfaces (manufacturing, marketing, advanced research and development, supply chain) and bring to light the most important aspects of their relationship with product development.
2.2.1 Manufacturing
Manufacturing is product development's direct client and has a significant influence on how engineering is done. The added value that product development creates by transforming information into specifications, engineering drawings, bills of materials and other product and process data does not become real until the product is produced and assembled. This reality makes understanding the details involved in manufacturing vital to product development.
Knowledge of manufacturing provides opportunities to the engineers of a product development group. Production staff can provide a realistic understanding of the capabilities of current manufacturing processes allowing engineers design parts that are robust to manufacturing variations. The dialog with manufacturing provides an opportunity to innovate in design concepts and process. Together, design concept and process can create an enormous competitive advantage for the company. Product development organizations must learn that working with manufacturing is one of the greatest opportunities to create value and innovate.
The nature and intent of interactions between manufacturing and product development change continually throughout the product development process. Some phases of the product development process are more naturally akin to generating interaction, such as during the launch of a new product. However, the 'define' phase, which is not naturally an interaction point, is the one of the areas where the most benefit can be gained. Understanding process capabilities, manufacturing site location and facility assumptions helps engineers design the product to make the most of the existing constraints. Keeping the relationship with manufacturing alive during all stages of product development helps improve the flow of information from customer need to finished product.

For product development added value is created and becomes tangible when the product is manufactured. This consideration must set the tone for all of the interactions product development has with manufacturing.
2.2.2 Marketing
Marketing provides the crucial interfaces between the customer and the company at all times. It is through this organization that the majority of customer input reaches product development. The influence of marketing is felt in how the target customer is selected and the main product requirements are defined. Marketing is therefore the main avenue for interacting with the customer and defines the quality of the initial capture of the voice of the customer. It is not sufficient to assume that the input from marketing will be easily understood by engineering; having marketing in the product development team is a must.
Complexity arises from the interaction with marketing and the fundamental differences that exist in what drives the different organizations. In each area there is need for people with different abilities and backgrounds, as a result creating a seamless interaction between both areas require time and work bridge these two worlds. This seamless interaction can build on the common ground of the customer and product being created. The multidisciplinary character of product development (Browning, Fricke, & Negele, 2006) increases the complexity of the interface with marketing, yet is a reality that product development leaders must embrace and manage.
2.2.3 Advanced Research and Development
New technologies and innovation are critical to the survival of automotive companies. Without these, competition soon catches up and eats into a company's sales. Pressures to deliver new products faster, cheaper and more reliably make innovation and advanced research almost impossible to conduct as part of normal day to day activities in the product development organization. The essential elements that drive advanced research and development organizations are fundamentally different to those of product development and must therefore be managed separately. However, the interaction between product development and advanced research and development is necessary for the implementation of new technologies in consumer products. Making this interaction better allows companies to develop the right technologies and implement them at faster rates.
The relationship between these two organizations must be one of continual dialog. Effective collaboration and transfers from advanced research to product development happen mainly during the initial stages of the product, yet continual contact is required to identify latent opportunities. For product development working with advanced research is an ability that must be grown strategically to create a continual flow of new technologies that are implementable and of value in the market.

2.2.4 Suppliers
The influence of the supply chain in the engineering process has been an area of interest since the 1980's (Simchi-Levi, 2002, p. 176). It was around this time that the impact of process and product design on cost became a widespread topic of conversation, and continues to be so today. In recent years pressures to reduce product cost and the increased need to tend global markets have made the supply chain even more critical.
Suppliers will be critical to successful manufacturing of a product. During the design stage changes to materials and manufacturing processes can be done for a fraction of the cost than they can once manufacturing has begun. Companies are cognizant of this situation and have worked to drive the needs of the supply chain into product development. The ability to work with suppliers to ensure that the design is executed as planned constitutes an important step toward having a fully integrated value chain.
Suppliers range form those able to supply full solutions (engineering, testing, production parts, service) to those that focus only on manufacturing parts to the company's specifications. For product development teams working with suppliers that provide engineering and managing the relationship effectively is a huge challenge. Inadequate balance regarding project is structure can quickly lead to severe cost penalties. Understanding the technical system that is at hand and being able to manage the risk of developing a new product are the key aspects of interfacing with suppliers during development. With good technical understanding it is possible to select the best solution and supplier for each subsystem minimizing the overall lifecycle cost of the product.
Good supplier management and relationships have been key to the recent success of Toyota. Their management of the supply chain has enables significant gains in manufacturing cost and more importantly enormous reductions in product development time and cost. Product development organizations that wish to design products that can compete against the likes of Toyota will have to learn to work intimately with suppliers.
2.3 Approaches to Modeling Product Development
The added value in product development is not realized until the product is manufactured. This makes identifying added value difficult, and as a consequence can hinder improving the execution of product development. Various methods to model and analyze product development activities have been developed and by reviewing them one can identify general areas of opportunity. Having been used for analysis of product development organizations the opportunities these methods bring to light provide excellent guidance toward improving product development.

Name Visualization Description Main elements Area of Oportunity
A VSM (value stream map) describes all the actions (both value added and non-value added) required to bring a product from -Remove information
-Flows M need to finished design. By using a diagram -Activities flow inhibitors
with data flows and activities it can identify -Delays -Ineficient information the areas where the current process is transformation stalling and help devise improvement actions (Shook & Rother, 1998)
Architectural object process methodology - 2? --- (AOPM) is a holistic integrated approach to -Objects
the study of systems where value delivery -Processes -Unmet needs and creation are central. The models -Needs -Undetected
OPM V ry integrates function, structure and behavior, -Beneficiaries beneficiaries
...... [ explicitly linking value is to the beneficiaries -Beneficiaries beneficiaries -
Jallowing for a complete representation of -Links
complex activities.
D-.M The DSM (Design Structure Matrix) ',represents the relationships between -Efficientize
-Elements (parts elements in a n 2 two dimensional matrix. interactions
or people or DSM Three basic relationships that can be -Unidentifiedactivities)
A' R LO represented: parallel, sequential and organizational patterns -Relationships
... coupled. For PD DSM's are normally made -Unclear interfaces
:. .......... . for: components, team and activities. c Eppin ge I
Figure 2-5 Areas of opportunity for better product development derived from process modeling techniques (Shook & Rather, 1998) (Crawley, 2006)(Eppinger, January 2001)
Analysis of the modeling techniques that have been developed also brings to light some of the
important variables that have been studied previously. These variables are all worth considering
when embarking on improving product development as they have been shown to influence the
outcome of product development directly. Additionally the areas of opportunity that the models
highlight coincide with some of the larger problems that are seen in product development
organizations.
2.4 Framework for Detailed Study of Product Development
To further advance our work in the development of the product development system, a general
framework within which to analyze the problem is needed. This framework must provide the basis
for digging further into each of the elements of the product development system, and become an
integral part of the architecture.
Having worked in product development, it is clear that when people try to comprehend how to
visualize product development there are normally two different views. The first is to look at the
elements that make up the product development activity, such as the process, product, goals,
people and tools (Browning, Fricke, & Negele, 2006). The second is to look at product development

almost purely from a process perspective, and identify the main tasks - define design, validate, launch. Experience tells us that using either approach separately misses key aspects of the realities
of product development. Therefore in this thesis we have made sure to consider both aspects.
To conceptualize a how to combine both points of view, the following framework was created:
STRUCTURAL Axis - describes the different elements of the product development system (Browning, Fricke, & Negele, 2006)
1. The product system is the desired result of the project - i.e. in the case of product development, the product "recipe" described previously
2. The process system is the methods and sequence followed to get the work done and the
interim results achieved to deliver the product system 3. The organization system consists of people assigned to do the work to produce the product
system. 4. The tool system represents the technologies used by the people to enable the delivery of
the work required to create a new product 5. The goal system that is the environment and requirements under which the other 4 systems
operate and drive the direction of the project
TIME Axis - describes the different phases that product development goes through
1. The define phase focused on achieving definition that drives team commitment 2. The design phase finishing a detailed design that embodies the product concept 3. The validate phase proving that the design delivers on customer needs 4. The launch phase manufacturing a product that meets customer needs
Combination of both these axes allows us to create a matrix where structural and temporal items interact and offer a combination that is favorable for undertaking the analysis of the product development system. The product development system consists of all the elements necessary to take customer needs and transform them into a manufacturable product - therefore our
representation must also meet these requirements.
Time axis
Figure 2-6 Matrix framework - time and structure approach to developing the product development system

Product development practitioners can testify that the relationships among each of the five structural components changes, depending on the development phase of a program. We can corroborate this by taking a look at the product development process of any automotive company; here, the relationships needed to advance the program change over time and are reflected in the required documentation and milestones. By using this representation, it is possible to visualize this changing role that the structural elements have while developing a new product.
Use of the time axis is critical to designing the product development system. It allows a way to easily decompose the product development system into parts that are temporally aligned. This decomposition can be used to define the work areas for future theses and achieve the goal of improving the whole product development system. Reintegration of the product development system can then be done using key aspects of the structural domain that are established by the system architecture. Each of the structural components defines standard interfaces for the system, while the time domain phases represent different operational modes.
One important observation that must be made is that this framework for approaching product development supports our consideration that product development is itself a system. Because of this, it can be analyzed and designed, and is consistent with the two axes presented above.
Using this framework, the following chapters will explore the structural elements of the product development system in detail and then move on to the architecture and design of the system.
2.5 Overview of Principles in Product Development
Design of a product development organization and analysis of its elements must start from an understanding of the principles that rule the best organizations on the planet. A principle is defined by the Merriam Webster as: a comprehensive and fundamental law, doctrine, or assumption. Having principles provides us with solid ground from which to begin improving product development. Two comprehensive sets of principles are presented here, one by Morgan and the second by Sobek. These principles help us grasp at some of the main conclusions serious studies into product development have obtained.
Product Development (Morgan J., 2002)
* A holistic, systems approach to product development. * A customer first approach to product development * A front loaded process. * Built-in learning and continuous improvement. * Synchronize process for simultaneous execution. * Use rigorous standardization to create strategic flexibility. * Go to the sources engineering.

Communication (modified from (Sobek, 1997))
* Make each product development participant responsible for finding the information s/he needs.
* Inundate product development participants with as much information as possible. * Use written media to communicate important decisions, considerations, and analysis
reports; supplement with verbal communication. * Use verbal, face to face communication for problem solving. * When possible always use written communication, followed up by verbal confirmation. * Focus cross-functional meetings on solving specific problems. * Minimize meeting time through judicious use of written communication. * Encourage communication between designers of different subsystems, because integrating
the designs of subsystems is primary. * Use regularly scheduled decision meetings to minimize overlap and ensure direction includes
input from all key players.
People and organization (modified from (Sobek, 1997))
* Hold product development leadership teams totally responsible for the project from concept through production and accountable to senior managementfor the success or failure of the project.
* Give product development team the autonomy to design their own organizations and design processes.
* Organize to develop families of products. * Appoint leaders who create a single point of technical leadership for the development
project. * Integrate vehicles by having a system designer that consolidates and synthesizes information
from all areas of the company and from the market. * Integrate subsystems by gathering together specialists andfostering mutual understanding. * Organize to give project leaders responsibility with little formal authority, but full
accountability. * Make the project leader's primary job the system design. * Define a program manager to lead the development process
Product and process (modified from (Sobek, 1997))
* Design a unique development process for each project; use a standard base as a template. * Plan the process by creating a simple overall plan and having project participants fill in the
details.

* Keep product planning and design process planning together in time and produced by the same people.
* Use customer and market data to inform target-setting in product planning. * Centralize top level process engineering and separate from product engineering. Collocate
implementation level process engineering with product team. * Minimize the barriers between designers and producers, because good engineering requires
a fundamental understanding of the physical world. (attained through hands on experience building things)
* Standardize processes and develop design standards in order to maximize learning and continuous improvement, speed up the design process and increase the reliability of designs
* Design new manufacturing processes concurrently with the product. * Study new process technology and develop standards before committing to it in production.
* Product development is product and manufacturing process-driven.
This list is a very complete view based on the agreed best practices and operational principles for
product development. This information is extremely valuable, but difficult to act upon. By designing a product development system and integrating these high-level principles in its architecture, real
use of these principles can be enabled. However, to achieve this, deep understanding of the
elements and structure of the product development system are required.
2.6 Key Takeaways - Product Development
This chapter presents a general overview of product development, providing a notion of it's function, relationships with other functional areas and a broad definition of how it generates value. The following list summarizes the key takeaways of the chapter.
1. The main activity of the PDS (product development system) is to transform information, starting with customer needs and ending with a finished design.
The working material in product development is information. What goes into the PDP (product development process) are customer needs and what comes out are detailed instructions on how to build a product that satisfies the customer needs, the finished product design. Therefore, the creation of added value for the PDS (product development system) depends on its ability to perform this information transformation efficiently (low cost and time) and effectively (ensuring that customer needs are met).
2. Product development is a multi-functional activity that requires seamless integration of diverse functions in a company.
Creating a successful new product requires many different functional areas to work in unison as a team. Because of this, to design a PDS it is critical to have intimate knowledge of the - internal and external - customers and suppliers of product development. By understanding these relationships product development organizations

can help streamline their processes and improve their ability to add value. This knowledge and understanding of product development's customers and suppliers is also important for the successful management of individual projects.
3. Product development definition and our approach to dividing it into four sequential process phases for analysis.
Product development will be defined as the following:
Product Development: The set of multifunctional information transformation activities beginning with the perception of a market opportunity (customer need) and ending in the delivery of a finished design, which enables production, sale, delivery and service of a product.
(Modified from Ulrich and Eppinger 2004)
The PDP (product development process) can be divided into four phases to enable analysis and execution.
1) Define - Achieve definition that drives team commitment by identifying needs, translating into requirements and creating a product concept
2) Design - Finish the detailed design that embodies the product concept achieving an economically feasible solution
3) Validate - Prove that the product as designed delivers on customer needs by comparing the design against customer requirements for compliance
4) Launch - Begin manufacturing the product as designed to meet customer needs by transferring and implementing the product design at the manufacturing facility
4. The PDS (product development system) can be analyzed as being made of five systems that are present and identifiable in all product development systems and their related PDO (product development organizations).
The five systems that have been identified are the following (Browning, Fricke, & Negele, 2006):
1) Product system - the desired result of the project and driving force to achieve alignment of all the product development system
2) Process system - methods and sequence followed to get the work done and the interim results achieved to deliver the product system. Is also a key enabler for coordinating multifunctional work
3) Organization / People system - consists of the people assigned to do the work to needed to deliver the product system by following a product development process. People are the main element of the product development organization and system, and will have the most influence over the success of a product development project
4) Tool system - represents the technologies and enablers used by the people to do the work required to create a new product

5) Goal system - represents the environment, motivations and requirements under which the other 4 systems operate. It drives the direction of the project and of the people that execute the work to deliver a new product
The relationship amongst these five systems must be designed with care to improve the PDS. In particular it is our task to achieve alignment amongst the five systems to ensure that we can effectively go from customer needs to a finished product.
5. Principles for good product development summarize key knowledge from the automotive industry.
As a group, the principles presented summarize much of the current state of the art regarding product development and help us highlight critical areas. For reference see Section 2.5 .
6. Key areas of opportunity identified from generic product development models.
The three modeling methodologies provide an assessment of value in product development and provide valuable insight to potential areas of opportunity.
* Information flow - flow of information from one task or process to the next in the value stream must be as efficient as possible
* Information transformation - the diverse tasks (engineering, design, costing and others) needed to deliver a product must be balanced and all perform well to avoid creation of bottle necks
* Detection of customer needs - clear identification of customer needs is key first step to allowing the PDS to deliver good products
* Identification of all beneficiaries - in addition to the final customer all beneficiaries from product development must be identified to increase the potential to create added value
* Organizational interactions - organizational architecture must be designed to facilitate development of specific products and be known to ensure that the team works efficiently
All key takeaways from this chapter help define the problem at hand and provide clarity on some of the terminology used thought the thesis. The PDS architecture will then grow from these definitions and leverage them to generate a consolidate design for a PDS.

3 Product Development in the Automotive Industry
Automotive product development is an area of great opportunity. Automobiles are probably the most complex products for which many examples of new developments are regularly released. Each year OEMs renew more than 25% of their vehicle line-up and develop hundreds of new technologies. Today, a new car represents the second most expensive purchase most people will ever make', making car buyers highly sensitive to the value proposal of the finished product. The ability to successfully develop new products and integrate new technologies to current product lines is therefore essential to the financial success of OEMs. Additionally, the automotive industry plays a vital role in the economy, in 2004 the United States alone spent the equivalent of 4% of the GDP on new vehicles (Ford Motor Company, 2004), while the number of new car models available was one of the highest ever; this makes the automotive business an attractive place to do business. Collectively these facts exacerbate the importance of successful new product development in the automotive industry and make a case for further work in this area.
3.1 General Description of Automotive Design and Engineering
Most automotive companies organize their engineering departments around the main vehicle subsystems - body engineering, powertrain, chassis, electrical, body interior. Differences in how each OEM (original equipment manufacturer) chooses to implement the organizational structure are driven by differences in product development philosophy (Morgan & Liker, 2006) and by the product development process (Clark & Fujimoto, 1991).
Pressures to deliver new products with a greater frequency have made increased reuse of vehicle components a must for survival (Morgan & Liker, 2006). Coherent sets of components have been designated by OEM's to facilitate the product development process (PDP) and are called vehicle platforms. Automotive vehicle platforms vary in their definition from one company to another, and this affects the extent to which components are reused. Until recently, most platform strategies focused on semi-integrated full vehicles that included main body structural elements, suspension and powertrain. From these platforms, OEMs proceed to use different outer bodies and interiors on vehicles, using almost identical mechanical components underneath. This, however, sometimes reduces the ability of manufacturers to fine-tune their vehicles for the needs of different customers. As a result a modular approach to automotive platforms has been developed in recent times. By using a modular approach, OEMs are can reap the benefits of having common sub-systems for vehicles, but gain in flexibility, thus allowing them to better meet customer needs.
1 Transportation and vehicle purchase are the second largest expense of US households (U.S.Department of Labor Bureau of Labor Statistics)

Figure 3-1 GM Automotive platform strategy (de Weck 0., 2006)
In addition to dealing with the normal complexities of engineering a complex system, automotive
product development must resolve the vehicle aesthetics and content (radio, A/C, safety
equipment, navigation, etc) (Morgan & Liker, 2006). These 'non-engineering' aspects of product
development, that are lead by the OEM's design studio, are key to a new vehicle's success. The
design studio is the department dedicated to conceiving new concepts for vehicles and defining the
aesthetic design of the vehicle; they transform the customer's voice into the vehicle design. With
the combined efforts of the design studio and engineering, the OEM takes the customers' needs and
creates a concept of what the automobile should look like. This idea is what is then developed and
engineered in detail to take into production. The role of engineering when it comes to aesthetic
design is making sure that the most accurate representation of the designer's concept reaches the
show room.
On a technical side, pressure to reduce vehicle weight and increase safety has pushed vehicle
construction toward converging on the use of steel unibodies for most applications. By using
unibody design, automobiles use sheetmetal as the load-carrying element in the vehicle and
eliminate the need for a separate chassis. For product development, using unibody designs means
that a significant amount of body engineering is done every time the vehicle appearance is changed.
An example of how important effective body design is to quick development of new products is
presented in The Toyota Product Development System (Morgan & Liker, 2006) and Product Development Performance (Clark & Fujimoto, 1991).
Figure 3-2 Unibody vehicle construction (Ford Freestyle body)

For cars, as with any other product, manufacturers have sought to improve their competitiveness by reducing cost, improving their offerings to customers, and making sure their product gets seen. In alignment with this, efforts to improve in the automotive industry have followed three paths: manufacturing, sales and product development (Morgan & Liker, 2006). Until recently, manufacturing and sales had been the most exploited areas, but now it is clear that it is product development where OEMs will find the most benefits.
3.2 The Product Development Process
Automobiles are complex enough products that there is a need for both functionally deep teams and project-oriented groups. The PDP (product development process) must be able support both, the development of improved subsystems and of full vehicles. Many times the goals of these activities are at odds, but the ability to align both successfully through an orderly process has proven to be a key differentiator between the best organizations and the rest.
As a consequence of creativity, innovation and the nonlinear nature of product development both the process and the organization that develops new automobiles must poses flexibility. The approach to the product development process must be such that both details and big picture are represented accurately. The actual product development process of each automotive manufacturer constitutes a competitive advantage and each company keeps the details in secret. Many authors have stressed the importance of process in product development and highlighted Toyota as a leader in this regard.
A common way of organizing product development processes is by dividing the problem into smaller chunks. Each of these parts is selected by identifying key inflection points in the development process that mark the transitions between functional groups, activities or team focus. Each of these parts is, as a best practice in the automotive business, followed by a milestone where a go / no-go set of requirements has been established to ensure product success. Doing this ensures that all the necessary information is available during the next step of the process and that the lessons learned from previous projects can be captured in the list of milestone requirements or deliverables.
As part of the process, most automotive companies have converged towards the best practice of using common documents throughout the organization and throughout the whole product development process. Doing so has made managing the information generated during the process much easier, and has allowed organizations to learn from their mistakes much more quickly. Standardization of documentation has happened at all levels, but lessons from Toyota indicate that driving standardization to the base working level will provide the most benefit. By starting at the lowest level, all critical technical information is standardized, and aggregation at higher levels is possible with minimum effort. Commonality at the execution level is one of the ways to reduce waste throughout an organization. It enables transparent communication and excellent lessons learned capability. Having pre-established document forms also reduces the time spent by individuals in each of the areas creating templates and forms. One of the difficulties of using

standardized documentation for different functional areas is that many times there are different needs for each of them. Even if commonality in documentation reduces the local efficiency of one or two processes, the increase in global efficiency for the product development system more than compensates. The automotive industry as a whole has embraced this manner of working to various degrees, but tendencies show that, for the most part, there is agreement that standard documentation is a best practice.
As we stated in Chapter 2 in this thesis we have divided the product development process into four generic stages:
* Define * Design * Validate * Launch
These four stages follow each other sequentially in time for the development of a new product. Within each of the levels the product goes through additional loops of define, design, validate and launch cycles that make up the entire product development process. In designing the product development system this four step approach helps direct our focus and simplify the problem definition.
3.2.1 Define Phase
To define the set of attributes for a new product requires a rigorous process of market research and customer need identification. The process of identifying customer needs and developing products to serve them requires that a multitude of activities take place in parallel. The activities that must be coordinated come from a variety of disciplines - marketing, finance, sales, manufacturing, engineering, purchasing - each having unique needs that must be accounted for to allow for coordinated work.
In this initial stage, both the concept and the assumptions that bound it are set. It is these assumptions that then trigger all of product engineering activities to deliver the detailed design (Clark & Fujimoto, 1991). The define phase is consequently critical to the success of the product development effort. During this phase the multiple inputs from all stakeholders must be considered and combined to capture the customer's voice in engineering requirements.
'User requirements are the first step towards defining a system. Every system needs to satisfy its end users to be successful, an so we must define who they are and what they want, expressed in their own terms'(Stevens, Brook, Jackson, & Arnold, 1998, p. 20)
The development of a new automobile is guided by user requirements. As such, the first step towards defining a new product is to understand and capture the user requirements. The task of capturing the requirements for the new product is one of the most difficult tasks in the entire

product development project. How well the requirements are captured has tremendous impact on
the development process and the finished product. This is partly because, using the requirements,
the concept is designed to deliver on all of the proposed requirements and achieve consistency
(Clark & Fujimoto, 1991). The number of individual requirements that a vehicle must meet is in the
thousands. For this reason, most automotive companies have an extensive database of technical,
government and market requirements that are used during the development of new vehicle
programs. Generic sets for predefined sizes of program are combined with particular requirements
for each project to deliver the full set of customer requirements. These last ones, those specific to
the program, are the most critical and difficult to manage.
In automotive product development the lead time for tooling parts can be longer than a year. As a
consequence, selection of suppliers for the vehicle is one of first activities that must take place.
Good foresight regarding the selection of suppliers and factors external to the engineering world
ensures that products go through product development process cleanly and are successful during
production. One of the benefits of selecting suppliers well during the define phase is the increased
synergies that can be achieved between the OEM and the supplier base, leading to reduced
production costs and better designs.
Sometimes the define stage is seen only as capturing user needs; however, it has other important
roles as well. The define stage prepares the team to embark on the project at hand and commit to its delivery. Commitment to the project is contingent on agreeing on many aspects of the vehicle concept and defining the work plan to enable the team to begin the detailed design process.
Achieving team alignment on the project is critical to success; teams that have achieved proper alignment have demonstrated exemplary performance down stream.
S * S
Function definition Business Strategy Concepts generation Functional Strategy Regulation Customer Needs Technology assessment Competitors Platform plan Program plan Supplier plan Business case Architecture creation Goals
Figure 3-3 Components of the Define stage and their outcome (extensively adapted from (Crawley, 2006))
As an end goal for the define phase, the project leader should strive to have all the elements necessary to achieve commitment of the team and higher leadership to the project. A good definition stage allows the team to divide the work efficiently and directs the team towards
delivering a product that meets customer expectations.
3.2.2 Design Phase
The design phase in a product development process takes the concept and drills it down to
component specifications and detailed designs that allow for manufacturing. During the design
... we mustl achieve
... A
Tem

phase, it is important to focus the organization on delivering solutions that meet or exceed
customer needs to ensure delivery of a competitive value proposition.
In the automotive business, the design phase is composed of a series of well-understood
engineering tasks that have been performed many times before. However, new situations arise each
time as a result of new technologies and changing customer requirements. The fact that there is a
basic process that is repeated time after time opens an opportunity to improve our execution of the
process and multiply its effect throughout the system. Incentivizing engineers to innovate and push
the barriers to improve the product development system is not trivial. A careful balance must be
achieved to enable use of best design solutions, yet continually challenge the status quo to improve
our products.
During the design phase, engineers work to find solutions to the problems posed by customer
requirements. Selecting the right solution is a tough challenge and a core engineering capability.
Extensive prior knowledge, back-to-back comparisons, benchmarking, design methods and customer
focus groups are some of the tools to help select the best engineering solutions. Toyota has been
acclaimed for what has been named set-based concurrent engineering (Morgan & Liker, 2006)(Morgan J., 2002), a process that allows Toyota to efficiently select the best solution for each problem. Good product development organizations have processes, methods and principles that
enable them to select the best solution for each design problem.
* Requirements definition Model development Requirements flow down Detail decomposition Interface control Design elaboration Goal verification Failure & contingency analysis
*. uw ut Figure 3-4 Components of the Design stage and their outcome (extensively adapted from (Crawley, 2006))
'The goal of PD is to create a "recipe" for producing a product' (Reinertsen, 1999)
As any good recipe a good design describes all the elements necessary to build a vehicle take the
product all the way through manufacturing. The outcome of a well executed design phase is a
finished design that will go through validation and launch with few or no changes to the design. This
finished design must meet the functional targets set by requirements and contains detailed
information on how to produce the new vehicle. The outcome of the design phase must be such
that we can achieve a true freeze in the design activities.
In the design of a product development system, the design phase is critical. It is in this phase that
the execution of most product development decisions takes place and therefore one of the phases
most susceptible to errors. For example, the set based approach to engineering has been widely
I Finihed Dsign

acclaimed because of the robust way it empowers managers to make the right decisions, and therefore greatly improves how Toyota executes their product development process.
3.2.3 Validation Phase
Validation allows the engineering group to evaluate the capabilities of the proposed product versus the requirements that were set by customers. This stage of the engineering process is particularly expensive because of the need for prototyping and therefore an extremely attractive area for reducing the cost of product development. Validation work must be accomplished keeping in mind that a correct balance of cost versus client delivered functionality is critical. Confirming that we deliver on the customer requirements is essential to insure that the product is successful in the market.
In the automotive world, validation is a costly endeavor that can entail the construction of full vehicle prototypes. In some instances the cost of prototypes can exceed fifty percent of the total engineering budget (Aguirre, Endo, Espinosa, Sacka, & Soto, 2006). The cost of validation is, however, weighed against the risk of delivering a product that fails to deliver on some critical customer requirement, and the system understanding that the team achieves through the process. Optimizing the number of prototypes and reducing their cost therefore significantly impacts the overall cost of product development.
'The outputs of product development activities such as information cannot be verified until much later.' (Browning, Fricke, & Negele, 2006). This places product development in a situation where risk management is essential. Many times it is necessary to take decisions whose impact cannot be measured until the first vehicle is built. To this extent, there is currently a huge push by all the automotive industry to begin using an increased amount of virtual tools that allow engineers from all areas to assess the impacts of their design decisions early on, with out the expense of having to build physical prototypes.
Sourcing Product testing Implementation Systemtesting Element implementationRefinement Element testing Certification Element refinement Market positioning Product integration
S Figure 3-5 Components of the Validate stage and their outcome (extensively adapted from (Crawley, 2006))
When validation is finished, there should be clarity that the part, subsystem and system levels of the
product are delivering to target and customer expectations. The auto industry has invested heavily
in taking subjective customer requirements and making them into objective targets. However, it is not always possible to capture the full extent of the customers' voice in an objective target, and validating the engineering work with customers is critical. The capstone event of the validation
phase is ESO (engineering sign off) and is only complete after all technical areas agree that the vehicle delivers the expected performance.
~

In production, hundreds of cars are made by the day, and, in doing so, almost everything that could
have gone wrong with the design will go wrong. When going through validation, having this in mind
is important, so the things that need 'polishing' are rectified before arriving on the assembly line.
One way of achieving this is by effectively integrating the manufacturing team and processes into
validation. Good validation should provide confidence that the product can go into manufacturing
with little to no design changes.
3.2.4 Launch Phase
Transfer of the product into manufacturing is an often-overlooked aspect of product development.
The ability of the product development organization to deliver the design successfully to
manufacturing and ensure that the vehicle is produced as specified is a core product development
competence. Many of the activities that will determine the fate of the vehicle in the market are yet
to be completed coming into this stage and must be executed with care to achieve a successful
product launch.
Good engineering sign offs from the validation phase almost always indicate successful product
launches. Therefore to improve product launch the product development system must focus on the
engineering sign-off.
Production ramp up Sales KO Distribution Operations Logistics Customer support *
3- Deivr ofdsg
Figure 3-6 Components of the Launch stage and their outcome (extensively adapted from (Crawley, 2006))
Launch represents the phase where the PDO (product development organization) creates value. It does so by taking the information contained in the finished design and transferring it to
manufacturing to produce a finished product. Before this point in time, all the work done by the
engineers has not yet come together in a full and saleable product. Because of this, being successful at launch can have a huge impact on how the product design comes to life, and the subsequent success of the vehicle in the market.
3.3 Globalization
The automotive business is no longer one that concerns only a few markets, but rather one that
spans almost every part of the globe. As a result, product development has also grown out of its original two or three locations for each company and has now found home in a many countries around the world. One of the reasons for this shift is the increasing competitiveness in the industry that has highlighted the need to lower engineering cost. In parallel, better low cost engineering labor has become available in developing countries, and has thus triggered the creation of low cost engineering centers around the world.

The intense competition that exists in the market place today has driven companies to seek new ways to increase the difference between their costs and the value proposition presented in their product. One way this has been done is taking labor-intensive tasks to low cost countries. This strategy has been so successful that some people have ventured so far as to say that, in the future, all service related jobs, and those that can be efficiently located at a distance, will move to the countries with the lowest wages (Farrell, Laboissiesre, & Rosenfeld, 2005). This push towards total off shoring is balanced by a shortage of low cost talent in off shore locations such as India, China, Mexico and others. This lack of sufficient talent, in itself, will stop the migration of jobs from developed economies to low cost ones, as qualified workers become scarce, and the cost of training unskilled workers overcomes the wage advantage.
Product development is under pressure to reduce cost, given that it can, on average, contribute five percent of a finished product's cost (Aguirre, Endo, Espinosa, Sacka, & Soto, 2006). Along with this fact, recent technological developments have made engineering products at different locations technically feasible. The option to off shore product development tasks thus becomes of great interest from a financial standpoint, becoming one of the prime candidates for remote employment (Farrell, Laboissiesre, & Rosenfeld, 2005).
Even with the natural aptitude of engineering to be off-shored, it is still necessary to rethink and adapt product development activities to achieve global product development. Some activities are easier to off-shore than others as they have clear-cut interfaces, but others that require more interaction can become difficult to coordinate. The automobile, with it's over one hundred years of history, has evolved into a product where modularization and clear subsystem interfaces have arisen, making it a good candidate for global product development. It is interesting to note that regarding offshoring, a recent report from McKinsey indicates that the point of equilibrium may be near. The following are three conclusions drawn from this extensive study (Farrell, Laboissiesre, & Rosenfeld, 2005):
* 'Offshoring will probably continue to create a relatively small global labor market'. The relative impact of offshoring practices to developed countries is small, even under the most extreme scenarios.
* 'Demand for offshore labor by companies in the developed world will increasingly push up wage rates for some occupation in low wage countries.' Because we operate in free economy supply and demand will tend to equalize the costs at both ends, eventually diminishing some of the advantages of offshoring.
* 'Potential global supply and likely demand for offshore talent are matched inefficiently'. Some locations find themselves overstocked with talent while other struggle to find it. This unevenness creates barriers to offshoring.'
In the automotive business, offshoring examples have already begun to appear; more than one OEM has already begun developing low cost product centers, such as GM in India and Mexico. The implications of a globalized product development competition have an impact on how product

development systems are designed. Product development organizations successfully embrace the new paradigm of global product development and mange to overcome the difficulties of long distance interactions will thrive in the XXI century.
3.4 Key Takeaways - Automotive Product Development
Automotive product development has evolved over the past 100 years into a structured activity that is ruled by well defined processes. Throughout this chapter a brief high-level overview of the current situation in product development has been provided and from here we can derive some key takeaways regarding opportunities and the future state of automotive product development. The following three key takeaways summarize the items we find to be essential toward achieving good understanding of the PDS (product development system).
1. The review of automotive product development highlights opportunities and problems that must be considered and exploited in designing a PDS.
a. Importance of product development processes and documents - development of formal processes and documents to conduct product development enable greater efficiency and allow an organization to learn. By having clear knowledge of how things were done previously it is possible to change the process and improve on the results. The automotive industry is in a privileged position to benefit from this situation as it has already embraced the best practice of using formal processes and common documents for product development.
b. Relationship of engineering and aesthetic design - the engineering and design communities must interact seamlessly to deliver automobiles that are successful. Although engineering must provide some guidance in regards to the physical limits that the car design can have, it is essentially engineering's job to find ways to deliver a product that is as accurate a representation of the original design as possible. Good resolution of the conflicts between the design and the engineering directions are so critical that it is a must for the product development project leader to have control over both aspects.
c. Selecting the right engineering solutions - ability to select the right solutions to engineering problems is essential to successful product development. Companies such as Toyota have demonstrated that selecting the right solutions can be done following a process that systematically drives better products - concurrent engineering. By carefully identifying when engineering decisions need to be made and allowing the engineering teams to work on several solutions 'concurrently' Toyota leaps ahead of the competition by ensuring that the latest technologies and market inputs are embedded in their new vehicles.
2. Modularity will be the next architectural evolution of automotive platforms.
Until recently most automotive manufacturers focused on generating vehicle platforms that allow them to offer a greater variety of products to customers without having to re-

engineer every part of the vehicle. However, this approach has limited the ability of automotive OEM's to deliver the exact vehicle customers want, and drives trade-offs that can be sub-optimal for the final customer. Therefore, the next generation of platforms will shift the focus away from the complete vehicle and toward having modular vehicle sub-systems - front suspension, rear suspension, seat structures, powertrains, structural elements - that allow OEMs to mix and match them effortlessly to deliver exactly what the customer wants. Aligned with this change in direction, the PDS will have to evolve to support design and development of modular sub-systems and the integration capabilities to piece them together.
3. Global product development is the trend in the automotive industry and having a PDS that is successful in these conditions will be key to success.
The traditional model where automotive OEMs could have centralized product development capabilities at only one or two locations worldwide is becoming insufficient for the needs of a global market. Pressures to lower costs and new markets in developing countries are pushing OEMs to grow product development capabilities at new locations. This change requires that the PDS be capable of managing the complexity that arises from having the product development team spread over different time zones and cultures. One of the factors that can enable a PDS to be effective in this global environment is the ability to clarify and define the interfaces among product systems, thus allowing teams at different locations to work effectively as a single group.
The takeaways form the high-level analysis of the automotive industry in this chapter help identify some of the key aspects that the PDS architecture must account for to be successful. The two trends identified - globalization and modularization - in the automotive product development must serve as guidelines for the architecture that must embrace these tendencies and thrive on them.

4 Communication in the Product Development Organization
Our ability to communicate complex and abstract ideas is an essential part of what makes us human. This skill allows us to interact in groups and engage in complex social behaviors such as solving problems and embarking on projects that require teamwork. Engineering and product development are prime examples of complex endeavors that rely heavily on teams and communication for their
execution. The best leaders and managers have known for a long time that good communication and successful teams go hand in hand. However taking this general notion and transforming it into
a set of specific actions and policies has been a challenge for many organizations.
'Design-be it mechanical or software is a complex technical and social process (Bucciarelli, 1994; Henderson, 1999; Hubka & Eder, 1987; Minneman, 1991; Rodden, King, Hughes, & Sommerville, 1994). Communication is an essential part of any design process and has been identified as a major determinant for project success or failure (Chao & Ishii, 2003; Hales, 2000). Many problems in design are due to poor communication (Allen, 1977; Clark & Fujimoto, 1991; Eckert, Clarkson, & Stacey, 2001; Eckert & Stacey, 2001; Moenaert, Caeldries, Lievens, & Wauters, 2000; Ostergaard & Summers, 2003; Sosa et al., 2002). Designers and software engineers may be located at different geographical sites and time zones. To ensure that 'out of sight' does not mean 'out of sync' (Hinds & Bailey, 2003), communication has to be adequately understood, organized and supported. It is, however, often difficult for design managers to ascertain whether communication as such is the problem, or whether it is a manifestation of, for example, inadequate process planning or personality issues (Eckert & Clarkson, 2003).' (Maier, Eckert, & Clarkson, 2006)
In the preceding paragraph Maier et al. present with great clarity the core ideas behind our current understanding of communication in product development organizations. Within this chapter we will look at this current body of knowledge for communication in product development organizations and will strive to create a few key insights.
4.1 Technical Communication
Effective communication is critical to success in product development. Much of the communication
that takes place in product development can be categorized as technical communication and can be studied as such, with the purpose of maximizing the productivity of product development organizations. It is however important to mention that product development organizations also conduct communication for a variety of other reasons that are important, but not critical to the design of the product development system.
Technical communication is not unique to product development - other organizations such as advanced research and development are contained under this definition and it is therefore important to clearly distinguish the unique aspects of technical communication within product

development. Katz (1982) has mapped the differences between different technical groups to aid in identifying the prevalent characteristics of each. The four categories identified are the following: basic research, applied research, development and technical service. Of the four we are interested, for the moment, only in product development; thus we will focus on communication that enables activity which is concerned with the combination of existing concepts, and in some cases new knowledge and principles, to delivering a new product. In addition to defining the activity of product development, there are other characteristics of product development teams that are important when looking at communication. Some of these are: the final product is normally consumer ready, work is done in multidisciplinary teams, the work is based existing knowledge, project length is short when compared to research and teams can be dispersed geographically around the world. These characteristics shape some of the team behaviors when they are working and become important to understanding communication within and outside the product development team.
In studying engineering and product development communities Thomas Allen, (Allen, Architecture and Communication among Product Development Engineers, 2007) has classified the communication that takes place within these communities into three categories. Using these three categories, Allen has covered the whole realm of technical communication in regards to the type of communication taking place, with each category corresponding to a basic communication need that must be met in order for the organization to accomplish its goals.
TYPE I: Coordination. Exists in almost all organizations and is needed to coordinate work. TYPE II: Information. Is required when knowledge is changing and there is need to keep staff informed. TYPE II: Inspiration. Needed for creativity and occurs by chance encounters.
In addition to having different purposes, each type of communication can be associated to being more or less akin to different organizational structures and requirements of particular architectural layouts. The architectural considerations arise from the unique sensitivity to physical separation that each communication type exhibits. In general it follows that the importance of physical proximity is inverse to the order in which the information types are presented; as such, TYPE III communication is the most sensitive to physical proximity.
For product development it has been demonstrated by numerous studies (Allen, Katz, Brown) that it is the 'inspiration' (Type III) communication that is the most conducive to innovation and the more critical type for enhancing the product development process. Inspirational communication is also the hardest to manage and measure because it is not easy to stimulate, with chance encounters at the right point in time one of the main avenues for inspirational communication. Thus it corresponds that correct architectural layout is one of the best tools to enable this kind of communication (Allen & Henn, The Organization and Architecture of Innovation, 2007). Architecture provides the people with space and time for the ad-hoc encounters and allows for engineers to interact more frequently. Furthermore, there have been many other attempts to systematize creativity and inspirational communication - many have been successful, and use of tools derived

form them, such, as the use of Obeya rooms and focus groups as means to promote inspirational communication, is encouraged.
Technical communication is also subject to the influence of organizational structure. When observing the influence of organizational structures on the probability of communication it has been found to be dominated by two variables: departmental and project (Allen, 2007). The project effect has been identified to be a function of the interdependence between the product subsystems and elements as dictated by the product architecture, with most of the communication occurring in alignment with the product architecture. Conversely, the effect of the department is dominated by the size of the group and the maturity of the technology; with smaller teams and more dynamic technologies enhancing communication. Of the two effects, project and department, it is project that has the greater impact on how communication takes place within engineering communities. Therefore, intimate knowledge of our product architecture when designing the organization can help avoid mismatches and enable leaders to use the tendency of people to align to the product architecture as a strategic tool in management decisions.
As in all forms of communication, within technical communication, we can identify four basic elements that are the basis of the whole communication process, which are the channel, the message, the source and the receiver. As a broad notion, all of these four elements must work in synchrony to achieve successful communication, and can be identified within our every interaction. Most of the research conducted within product development organizations (Allen, Katz, Griffin, Tushman) aligns with this notion, and we find that although conclusions form each study may be slightly different, good alignment of the four elements is always critical.
One of the main sources of misalignment comes from the multidisciplinary nature of product development teams and the inherent differences in 'language' that this entails. Product development teams normally have at least engineers, marketers and manufacturing engineers working together to deliver a product. The differences in the 'languages' each groups speaks can lead to significant communication barriers; we must be aware of this to avoid major disagreements. In general each area normally speaks in the following manner:
* Engineers speak in terms of product features and specifications, and think about the product in terms of problem solving. (Griffin & Hauser, 1992)
* Marketers speak the language of the customer and are customer oriented in their approach to product problems. (Griffin & Hauser, 1992)
* Manufacturing speak of utilization rates and process specifications, and think about the product problem solving in terms of manufacturing feasibility.
As we can see, there are some fundamental differences in what each area talks about and is interested in. This leads to difficulties in communication and disparities in priorities throughout the development process. These differences, in reality, should not be as large a problem, since the objective of the whole team is to meet customer needs and requirements. Control of these

disparities must be done at all cost, with one way of solving the problem being the implementation of processes such as QFD to ensure transparent sharing of information and efficient communication.
Having briefly covered technical communication and some of its nuances, the next two sections will be devoted to communication within the PDO (product development organization) and outside the PDO. This distinction is necessary because some of the fundamental differences in the objectives that each pursues.
4.2 Internal Communication
Numerous studies and general management intuition have identified communication within the organization to be critical to success as can be seen in the quotes below. In particular, within product development organizations, internal communication quickly transitions from being a 'nice to have' item, to a 'must have' if the organization has any thoughts of becoming an industry leader.
'Innovation depends on invention and ideas, and this and other research finds consistently that the best source of new technical ideas for product development engineers is a colleague in the same organization.' (Allen & Henn, The Organization and Architecture of Innovation, 2007)
'Roughly 74% of the managers sampled from companies in Japan, Great Britain, and the United States cite communication breakdown as the single greatest barrier to corporate excellence.' (Hall, 1973)
Innovation and new products have already been identified as key to overall company success. The link found by Allen et al. and many other researchers between internal communication and the performance of the product development organization make it important to understand what organizational units, information types and communication methods are most important when attempting to improve internal communication. Hall 1973, in his interview of managers, proved that this perspective is supported not only by academics, but is also widely accepted amongst managers.
Internal communication is defined as being that which occurs within an organization, and, as such, is dependent on clearly understanding what constitutes the boundaries of the organization referenced. To some degree, our understanding of where the organization begins and ends can change depending on our approach to the problem. In the body of existing knowledge authors take different postures with some naming communication between manufacturing, marketing and product development 'internal' and others 'external' (Katz), (Allen), (Griffin & Hauser). In our case, internal communication will be defined as that which occurs within the context of the complete organization (i.e. that includes: manufacturing, finance, manufacturing, engineering) unless specified otherwise.
For communication occurring within an organization it is sometimes difficult to asses how large the cost of inefficient communication really is. However, empirical knowledge and experience from

automotive product development points towards concluding that the cost of inefficient communication may be much higher than expected. This is to say that the added value of the inefficient communication is commonly less than the cost of time expended by the people involved in the exchange. An accurate description of the kind of communication that is undesirable is that which serves no real purpose and adds no value. Communication is therefore not cost-free, yet is critical for successful product development. This, makes enabling efficient communication a key managerial activity.
4.2.1 Interactions and Information Exchanges
Information exchanges within the organization occur between a variety of different entities. If forced to prioritize, looking at the internal customers and suppliers of an organization renders a better understanding of the minimum communication interfaces that should be occurring.
'Development projects performed better when group members maintained higher levels of internal communication with other members of the R&D staff and with members of other organizational divisions, especially their clients in marketing and manufacturing.' (Katz, 1982)
For product development, the main customers are marketing and manufacturing, and upon closer inspection, these are also the most important internal suppliers. Product development requires a continual input of information that is transformed into the product; both marketing and manufacturing provide, on one side, the boundaries of action and on the other, an end goal for the product. This relationship is not unique to product development, but does make it essential for the product development team to ensure that communication is carried out flawlessly. QFD (Quality Function Deployment) is one approach that has been well documented towards ensuring enhanced marketing-manufacturing-engineering communication and has been successfully applied in a variety of industries (Griffin & Hauser, 1992).
Table 4-1 Summary of communication interactions. Modified from (Griffin & Hauser, 1992) & (Katz, 1982)
Author Classification Description Interfunctional Communication within the functional area
Communication with other functional areas within the Griffin Intrafunctional coorporation
Management Communication with/to management Communication amongst all members of the project
Intraproject group Communication between project members and other R&D professionals within the same functional
Departmental department Communication reported between project members and R&D professionals outside their functional department
Katz Laboratory but within the R&D facility Communication with other individuals outside the R&D
Organizational facility but within the corporation Communication with professionals outside the
Professional organization (external communication)
Communication with external operational areas, such as Operational vendors or suppliers (external communication)

In addition to these main entities that require communication with product development, there are
many other interactions that need to take place. Some happen within the subgroups, such as task
assignment, and others happen with other organizations like finance, or come from the top of the
organization in the form of corporate messages. In order to deal with this diverse variety of information, different approaches have been used to classify the information collected during research. Two of these have been summarized in Table 4-1.
Analysis conducted by Griffin and Katz using the described categories [Table 4-1] leads to some interesting insight into the differences between high performance and low performance teams with
regard to internal communication. In general they conclude that high performing teams have higher levels of communication intra-functionally and inter-functionally, with reduced needs for
management communication. Additionally, teams working under a QFD scheme to enhance their communication among functional areas used less time communicating planning activities and spent much more time communicating design-related knowledge. It is therefore desirable for team leaders to create the necessary conditions for their teams to exhibit the communication traits of
high performing teams.
4.2.2 Integration Teams
Integration teams play an essential role in facilitating internal communication and leading intra- functional and inter-functional interactions. On many occasions, integration teams will focus on milestone planning and resource allocation, and pay little attention to the quality of communication between component teams (Sosa, Eppinger, & Rowles, 2007). These teams, however, have the opportunity to lead high quality information exchanges and general product development improvement through these neglected interactions. Without attention to quality in these cross- component team communications, it is possible to waste valuable resources and have a false sense of security regarding the status of the team.
Data integrity and communication quality are, however, difficult to assess even when the integration team recognizes the need. As an example of this problem, within the automotive business it is standard practice to conduct engineering design reviews with cross-functional teams, these reviews can be either highly productive or wholly unproductive. Assessing if the design review has a positive impact on the team is not straight forward and is highly dependent on the ability of the chief engineer to lead the teams in the right direction. One way to maximize communication effectiveness is to develop guidelines in order to ensure proper execution; however, it has been seen that incorrect interpretation of these guidelines can lead to even worse outcomes. A welcome, but sometimes unintended, aid for maximizing internal communication is the participation of experienced personnel, be it in the form of the engineer, manager or chief engineer, within the review. Individuals with experience serve as 'smart filters' for enhancing our communication, ensuring that critical conversations and exchanges take place. In addition, these individuals will normally work outside their boundaries communicating guided by their experience, managing to override missing links in the process or team structure (Sosa, Eppinger, & Rowles, 2007). These traits

can be desirable when well directed, but must be kept under control to ensure that the organization
is kept aligned. Positioning high experience individuals in positions where integration is possible, be it at the function or project level, is desirable and has been seen to have positive effects on project outcome when properly deployed.
Having experienced people in roles that allow for integration supports one of the strategic purposes of internal communication, which is to relay best practices from one part of the organization to
another to promote organizational learning. When we refer to best practices, it is almost always the
case that the method, technique and/or knowledge has been proven to be effective at the source, and one would expect that transfer would be natural and trivial. It has been seen, however, that this
is seldom the case, and that, more often than not, organizations have enormous differences in the
way they operate amongst different units. This problem has been studied in detail and has been
named 'internal [information] stickiness' (Szulanski, 1996); we will cover this, and organizational learning in general at greater length within Chapter 5. Having experienced people relay best
practices throughout the organization is one way to alleviate this problem. Enhancing internal
communication will act to our favor in both short-term, by improving our development process, and also in the long-term by facilitating organizational learning.
4.2.3 Influence of Culture on Internal Communication
The influence of culture on the probability of communication amongst engineers was demonstrated to be very little when changing the mean distance between engineers for North American and European companies (Allen, 2007, p. 26). The lack of evidence to support or dismiss with any certainty differences in communication due to culture in countries with significantly different
profiles prompted a study by this author on communication amongst product development organizations in three different countries. The research was done by means of face to face
interviews with a total of twenty five individuals. All participants in the interviews were North
American Car employees and all worked within the product development group. The discussion and
questions on communication were brought along as a follow up to the general survey on product
development. Although the research was not done in the same fashion as in the case of Allen or
Katz, evidence collected from the interviews strongly suggests that there is a strong influence of
some cultural factors in the kinds and quantities of communication that takes place at each location.
In Figure 4-1, a summary of the cultural aspects that were seen to influence communication at each
location are presented. These aspects have been generalized to gain direction in regards to where
management changes and actions can best help the organization achieve its potential in terms of
communication.
1) Hierarchical Cultural Norms - Significant differences in the response to hierarchical models was observed. Both excessive respect and disrespect lead to undesirable communication patterns that are guided by the amount of stress and work pressure generated by these cultural norms.

2) Value of Social Communication - Social communication has different objectives in the work place at each geographic location. Subtle differences in topic, execution and social
incentives leads to changes in the informal/social communication that influences the overall
effectiveness of social encounters as an opportunity to conduct inspirational communication.
3) Planning - Execution and creation of plans for team structured communication drive a large part of the project communication. The team's ability to plan and adhere to the plan increases the effectiveness of communication forums and social encounters.
4) Formality - Increased levels of formality in daily interaction between coworkers modified the communication patterns.
Figure 4-1 Cultural aspects that influence internal communication between different geographic locations
The information collected provides some high-level pointers at what the possible levers to improve
communication might be at each location. Additionally, it broadens the scope of possibilities and
identifies what seem to be the main differences to those involved in the different product
development organizations.
It is clear that not all cultures communicate naturally in the same manner - such is the case of
differences identified between the communication preferences of Toyota and Chrysler by Sobek
(1997). In the review of communication variations of these two automotive companies it was identified that Toyota preferred the use of written means to communicate decisions, whereas
Chrysler favored the use of forums where face to face communication was possible. This leads us to
believe that to effectively improve communication within a PDO (product development organization) one must at least consider the four elements of culture defined above - hierarchical norms, value of social communication, degree of project planning and social relationships formality.

4.3 External Communication
External communication by product development organizations is critical to their overall success. It allows the team members to have better interaction with their clients and develops key team alignment via intimate knowledge of the voice of the customer.
'The underlying premise is that communication among project team members and with outsiders stimulates the performance of development teams. Thus, the better that members are connected with each other and with key outsiders, the more successful the development will be.' (Brown & Eisenhardt, 1995)
The exact manner in which a development team obtains external information is, however, as important as how much information is available. The communication channel therefore becomes critical and has been seen to be a function of the rate of change of technology, the uncertainty in the project and the communication impedance that exists between parties (Tushman & Katz, 1980). In this discussion, we will assume that there are two basic models for external communication: a spoke-and-hub model and a peer-to-peer model. Both models have been researched in depth in a variety of contexts and a few common conclusions from this research can help determine how to develop successful external communication that is cost effective.
4.3.1 Spoke and Hub
For the improvement of external communication at the professional level, the use of 'gatekeepers' as described by (Tushman & Katz, 1980), has been seen to be one of the most effective ways to achieve the desired output. Gatekeepers can also be related to the more recent description of 'connectors' in the best selling book The Tipping Point (Gladwell, 2002). In general these and other sources (Allen, Brown, Cousins, Lawson) conclude that in most organizations there are individuals who are best suited to interact with a large number of people inside and outside the organization. Both inside and outside, communication must converge in one person if the information coming into the organization is to reach the required people and become an effective path to external information. Within the model of spoke and hub, gatekeepers have been identified as one of the communications channels that allow for increased external communication (Tushman & Katz, 1980, p. 1084). Gatekeepers are individuals that have the necessary personal contacts, knowledge and organizational position to develop the role of an information hub for the organization.
The role of gatekeepers exists because organizations tend to specialize in technical domains in order to become more efficient at processing information. In doing so, organizations develop language and knowledge barriers that make communication outside of the local area difficult, expensive and time consuming. To bridge these barriers, people that speak the languages of two or more technical areas or different company departments become very important. Similarly, it has been proven that when the barriers to communication are few, direct peer-to-peer communication is significantly more efficient.

In development projects, gatekeepers are effective when there are different technical languages and coding schemes, such as those presented in Section 4.1 between marketing, manufacturing and engineering. This can also be the case within a same technical specialty, but where the parts involved find themselves at different points of the learning curve. Partial evidence was found that development projects that had gatekeepers performed better than those without (Tushman & Katz, 1980). However all of the past research has focused mainly on the performance of the team that has the gatekeeper, but little to nothing has been said of the teams that interact through a gate keeper. This is an important aspect of external communication when dealing with large transnational corporations. Such is the case of NAC, where development teams are located around the world and communication amongst them is critical for overall corporate product development efficiency.
In the case of a development project between Japan and Mexico the task at hand was the integration of a new transmission into an existing vehicle. In the development of this project Japan was observed to use the gatekeeper model more extensively, to the point of providing only one contact name for the whole project. In this instance the Japanese designated 'gatekeeper' was tasked with finding all relevant information for the project outside the organization and then distributing the information amongst the product development team to best suit their needs. Using gatekeepers worked well internally for the Japanese community, allowing them order in their development process, reducing the amount of waste information generated and streamlining their internal process. However, it severely limited the bandwidth of the communication occurring between the two working communities. Interactions with the Japanese community would occur through a main contact point that would then assign the question or task and return an answer at a later date. This process, on several occasions, diluted the possibility of creating better interaction mechanisms and limited the interactions to those established in the process. This negative, however, also had a positive side in that it allowed for rigorous procedure and process execution.
Although it has been stated by rigorous investigation that use of gatekeepers maybe positive for development projects, we can see that some of the external effects of this are not always positive. This does not imply that gatekeepers are unnecessary, as we will see with an example in section 4.3.2, but rather that for optimization in large organizations care must be taken when using this approach. In the research conducted by Tushman and Katz more that 60 percent of the projects did not have gatekeepers, stresses the point that gatekeepers are not always naturally occurring individuals within organizations. Therfore, it is important for managers to acknowledge that gatekeepers must be developed to enable communication when large communication impedances exist.
4.3.2 Peer-to-Peer
When communication takes place between a receiver and a source that have the same language and a low communication impedance, the effectiveness of peer-to-peer communication is exceptionally high. Furthermore, the addition of extra communication steps only reduces the clarity of the message being transmitted. It has been demonstrated, however, that generalized external

communication on the professional level does not necessarily lead the team to better project execution, as measured by Allen.
'Increasing the direct external professional contacts of development and technical service group members, on the other hand, has not been positively associated with higher project performance' (Allen, Lee, & Tushman, 1980)
Having said this, it is important to realize that project performance in large corporations is not trivial to measure and that local optimization achieved by isolating one development team may well negatively impact the rest of a development organization. In this regard peer-to-peer communication may well reduce efficiency for one party, but becomes an asset to the whole corporation. When observing the development project presented in section 5.3.1 from the Mexican side we identify the use of extensive peer-to-peer communication.
The Mexican engineering team was seen to avoid designating a single point of contact and worked by allowing each responsible team member to gather the relevant technical information and conduct most of the project interactions. For the Mexican team, which did not use gatekeepers, each team member would individually seek the information needed for the project and interact outside the organization. The inflow of ideas and information to the team was seen to be greater than in the gatekeeper model, although the quality of the inflow was not clearly better or worse. Multiple directions and information sources were created and as a result, at times, clarity in project direction was lost. This was compensated by the fact that the development team on the Mexican side was five to seven times smaller that that on the Japanese end. To a degree, the peer-to-peer communication in this small team generated a higher number of new ideas, with some coming to fruition as important enablers to the project completion. Some efforts were, however, duplicated and infeasible options explored because individuals were unaware of the bigger picture of the project at all times. In addition, at times it was difficult the Japanese team to identify who the right person to receive the information was, which lead to the Japanese gatekeeper choosing a point of contact that may well have not been the best. Here, use of a gatekeeper would have minimized these inefficiencies, but would have been decreased the learning each team member obtained and other positive feedback received after project completion. Feedback after the project to the Mexican team highlighted the great level of devotion to the project and the full time availability of human resources that the team demonstrated. In addition, quicker initial responses to technical questions were possible once the right contact had been established, although the time to issue resolution was not obviously shorter. Many of these interactions eventually lead to more efficient means of conducting the development work and effectively reduced development times and costs from initial estimates.
In general, the peer-to-peer model worked well for the Mexican team even though for some items there were huge communication barriers, beginning with language (Japanese versus Spanish). This is attributed to the small team size, good leadership, clear project direction, low uncertainty, some experience and team spirit. This last item, team spirit, may be hard to quantify but a generally

younger, more eager, group of engineers formed the Mexican team and helped overcome some of
the barriers that normally inhibit communication.
Peer-to-peer communication can lead to finding more efficient ways of working, and can lead, under
the right circumstances, to innovation. However this requires great compatibility among the team
members and great clarity on project direction. Use of peer-to-peer communication can lead to positive results as demonstrated with the project example that has been presented, however the downsides can at times be unpredictable and careful management of these interactions is required in order to reap benefit.
4.4 Communication Medium and Forums
The communication medium has a large impact on how effectively we can communicate. This
impact is seen in both the temporal aspects and the social connotation of each channel that we have
at our disposal. As was discussed earlier, effective communication strategies require that channel, source, receiver and message be in synchrony for effective communication. In recent years, the available channels of communication have multiplied and this has brought new opportunities and challenges. The influence that the selected communication channel can have on the overall performance of a product development organization has been proven in a comparative study between Toyota and Chrysler by Sobek (1997). In his study, Sobek identifies how different approaches lead to distinctly different product outcomes and required different management techniques. This evidence leads us to require a more careful examination of the communication medium we select, and analysis of the pros and cons each medium present.
In a similar consideration, there are a variety of forums in which communication takes place. These
settings are also meaningful in their impact to the organization's ability to communicate, and lead to
the creation of a communication culture within the group, whether intended or not. In defining how we manage our communication forums, we can lead the development team to enhance or reduce their performance in different areas. It is the management's responsibility to take the company needs and match them to communication strategies that best align with these objectives.
4.4.1 Meetings, Design Reviews and Informal Encounters
Communication normally takes place in a variety of formal and informal forums. Each have there unique characteristics, advantages and disadvantages. Allen et al (1980), in their review of communication within technical environments, found that a great deal of the communication that is valuable to product development teams take place outside formal settings. Situations such as meeting for coffee, or bumping into colleagues in the hallway were correlated to inspirational communication and led to linking building architecture to product development performance. In addition to informal encounters, there is also need for formal communication forums such as meetings, and, in the case of product development organizations, design reviews. Both design reviews and other meetings provide spaces for a predetermined set of people to gather and discuss

topics that have been formally established. In these forums the organization normally develops 'coordination' and 'information' communication exchanges, which form the backbone for a great part of the organizations daily activities.
Meetings are the prevailing form of formal communication forums within the industry, and design reviews constitute a special subgroup of these, that are of special importance to product
development. Design reviews are meetings that are ideally aimed at preempting issues and have as
an objective to work on the engineering issues in a team setting. However it was observed that within NAC, these meetings were intended to be communication forums and not issue resolution arenas. This item was identified during the interviews to be a key issue to successfully solve problems.
One problem that engineering managers often confront is how many design review meetings should a team conduct. Both product and project variables affect the optimum number of meetings and a deep investigation into this subject by Loch et al. has produced useful guidelines.
'The optimal meeting frequency follows the frequency of engineering changes over time, and it increases with levels of uncertainty and dependence.' (Loch & Terwiesch, 1998)
It follows without further explanation from the Loch et al. quote that the optimum meeting frequency, within product development organizations, will be extremely often, given the uncertain nature of product development. However, meetings have diminishing returns in their ability to reduce future problems in the project. As a result it is possible to mathematically derive some conclusions regarding how many meetings a design team should optimally carry out. The general the conclusion reached mathematically is similar to what many mangers have obtained empirically through their experience in product development. The two conclusions are:
1. Extensively frontload the project with design review meetings and then extensively overlap next development stages.
2. Avoid design review meetings and then proceed in a sequential development fashion. (leads to lengthy and uncompetitive product development times)
The preemptive nature of design reviews is such that, unless extensive and adequate upfront planning work is done there, the value diminishes quickly. It is thus advisable that projects frontload their design work extensively to support productive design reviews and then finish the development process by having overlapped stages. This idea is in accordance with current development philosophies and with North American Car's product development process that emphasizes the
concurrence of design, tooling and testing stages to compress development times and costs.
Reductions in the number of regular 'status' meetings and optimal location of work teams have been seen to help minimize the need for formal meetings to resolve problems, and enable meetings to become exposition forums. At the same time, the number of meeting attendees can be reduced by implementing the use of written communications as the means to communicate decisions,

instead of continuously using full team meetings for this purpose. As an aid to both these
techniques, good definition of roles and responsibilities has an overall positive effect on the number
of meetings each individual must attend and increases the communication efficiency.
Within project teams at North American Car, a few interesting characteristics of design review meetings have been observed. First, when teams are working well, even if project complexity is high, there will be low management presence in meetings. Second, leadership of design review
meetings can easily become a matter of political power; with both project management and engineering battling over ownership. Third, over-definition of meeting content worsens meeting
quality and drives attitudes that inhibit problem resolution; a balance of definition and flexibility is necessary to make meaningful progress. Because of these problems, formal design review guidelines
have been developed, yet lack of discipline and other external factors have not allowed for full
deployment.
Returning to informal encounters, it has been seen that for processes that require creative activity, the ability to foster informal communication becomes an important role. Nonetheless informal
encounters are without value if there is nothing to share, and it is here that formal forums are
important. Informal encounters can be stimulated by enhancing the environment and providing
opportunities for random encounters, such as coffee stations. Formal forums can benefit from
increased structure and alignment to process to maximize their impact, as well as from best
practices such as setting uniform expectations and having data driven discussions. Together, formal and informal communication forums play an important role in defining the communication culture
of the organization and can lead to improved team performance.
4.4.2 Media - Face to Face, Video Conferencing, Phone and Email
In recent years, communication in the office place has been changing significantly with the
appearance of email, mobile telephones, and other communications means. The abundance of new
electronic communication media has driven change within many organizations and changed
traditional structures and social behavior. As an example, email has in recent times taken the top
spot as the prime business communication means and reduced written communication time from
days to seconds. This has had the effect of undermining the importance of personal contact and
changed how people interact.
The phone, email and on occasion video conference are by far the main means of communication in
the organization today. All three media boast of almost instantaneous message transfer and
feedback with parties that can be as close as the next cubicle or on the other side of the planet.
These characteristics have made these media grow in importance and strength for organizations in the past decades.
'More important, perhaps, is the fact that the telephone and e-mail are what we might call, "bandwidth limited".' (Allen, 2007)

As stated by Allen, however, these media can limit the amount of real information that is exchanged and in doing so reduce the ability to innovate or solve problems. The importance of oral
communication in development projects can not be underestimated. As such it is important to consider our effect on project member interaction when setting up a team, their location and organizational structure (Katz, 1982), even with tools that allow for communication at great distances. As a note to this research, it is important to have in mind that new communication media
such as instant messaging have been coming online recently and that with these new opportunities to enhance communication may arise.
Of particular interest is the effect of email on written communication. As a rule, written
communication should exhibit three qualities that outnumber the rest: clarity, brevity and
directness (Bromage, 1970). These are characteristics that enhance communication efficiency, but that are seldom seen in work environments.
Noncommittal writing is engendered in the situation that is fraught with numerous unknowns. In a major business entity, such unknowns range from the expanding number of readers for any one document to diversity of technical matters; from
uncertainty as to timing for a touchy message to choice of media whereby to transmit it. (Bromage, 1970, p. 46)
Organization members have learnt that written communication can quickly have negative consequences for themselves and are thus reluctant to writing in a clear, concise and direct manner. The increased use of email exacerbates this problem as it becomes easier to use written media, and
in effect reduces the efficiency of each communication message. The effectiveness of email in
improving communication is therefore directly correlated to the organizational culture and the trust
that exists between source and receiver. Email should be seen as an effective communication tool,
but should never replace other communication forms, especially if its use requires the exercise of
contorted inaccurate language to avoid potentially dangerous situations for either party.
Even with their disadvantages, small, carefully planned meetings can be better than the use of written media. Forcing the team to meet face to face can be a tiring task for project leaders, however the upside to this communication is in general in excess of the effort expended. For
engineering teams this is even more true given the complex nature of the problems at hand and the
difference in technical languages that exist from one specialty to the next.
Working with multinational teams the use of less than optimal communication channels becomes a necessity. Under these circumstances, teams must develop countermeasure to these problems to
effectively deliver the project.
The greater the distance between sender and receiver, whether in point of view, geography, cultural patterns or level, the greater the hesitancy and holding back. (Bromage, 1970, p. 49)

Factors that affect effective communication are organizational size, sensitivities, distance, the
nature of the message. All tend to diminish message clarity, conciseness and directness.
Acknowledgement of these realities in communication can help team leaders enhance the
performance of their projects by identifying critical areas and removing the barriers that avoid communication.
4.5 Enabling Communication in Product Development
The communication process is one that cannot be controlled, only influenced (Maier, Eckert, & Clarkson, 2006). As a result, improving communication within an organization is a complex undertaking that requires careful matching of social and technological aspects. Knowledge of tools
available to produce a diagnostic of communication within the organization and the methods to
improve specific aspects are accordingly of value to organizations. Both assessment and
improvement will be addressed in this chapter, focusing primarily on tools that are well suited to
product development and that have already shown success.
4.5.1 Communication Assessment
Our ability to have a firm understanding of where the communication issues lie within an
organization is important to defining strategies to improve communication. Within product
development communication issues lead to difficulties in solving technical problems and diminished
team performance. Two different approaches are presented to assess communication. The first, DSM (design structure matrix), follows a structured approach and attempts to formally identify areas where communication that should happen is not - it does not, however, give any indication of
the participant's personal opinion of communication presently or in the future. The second, maturity
grid, evaluates communication subjectively and allows for direct participant input to the communication improvement process right from the start. In aggregate both methods present a
useful perspective on the status of communication and a future desired state.
Sosa et al. (2007) propose that management identify communication failures using the DSM (design structure matrix). The proposed approach to using the DSM is shown graphically in Figure 4-2 and consists in comparing the DSM matrixes for the product architecture and the team setup. The
comparison generates a third DSM named an alignment matrix that highlights mismatches. The
mismatches between the product design and the organization highlight areas where there are
communication problems. The mismatches can be classified as either unattended interfaces or
unidentified interfaces, with each representing a different kind of fundamental flaw in the
organization. Unattended interfaces have been seen to occur more frequently and are normally the result of teams that come from different parts of the organization. On the other hand, unidentified interfaces are less common but can have either positive or negative connotations. Amongst the positive connotations, they can identify areas of contact between teams that are necessary but

currently not formal, these can then be integrated to the product development process and organization.
Design Interface Matrix Alignment Matrix Key
Providing corrtponents Matched interface: design
81 C D Component A depends interface that is matched by System . on component D
an actual or expected team
Architects' A interaction
identify techrcal C Alignment Matrix Unattended interface: design
-- lisl Minterface
identfied by system
interfaces between | C Providing component teams arcitects that lacks corre- components D B D spending team interaction
A Unidentified interface: team t Minteraction that takes place
Team I iteraction Matrix 9 or is expected to take place Providing teams without a corresponding designinterface identified by system
Design A C D architects Teams' A Input ack of interdependence:
determine tecdnical components that do not share
interactions teams 23 C an interface or involve design have had, are havin g, T team interactions
or expect to have Team C requestsirfor mation from Notapplicable team D
Figure 4-2 Using the design structure matrix to identify communication problems (Sosa, Eppinger, & Rowles, 2007)
As presented, the DSM clearly highlights where there are mismatches within the organization that are leading to poor communication. These mismatches give clear direction to management as to where the problem is located and Sosa et al. propose that in an ideal state no mismatches exist. It is proposed that in order to solve a mismatch the following three alternatives be evaluated and implemented as required.
1. Review organizational and system boundaries 2. Form teams to handle mismanaged interfaces 3. Select appropriate communication support tools
The DSM approach, however, does not truly involve the organization in assessing communication problems or in defining what the future state should be. It is therefore in many senses an outsider to the organization, and can therefore lead to increased resistance to accept change. Even with this last point in mind, use of DSM in resolving communication issues has been proven within engineering organizations with great success. Of special importance is the ability to visualize the communication in a graphical form and present both organization and product architectures in a single element.
4.5.1.2 Maturity Grid
The maturity grid approach proposes that the team should be involved in both the assessment of communication and the setting of the desired future state. This method in particular has the advantage of raising the awareness of the importance of communication in the organization and promoting involvement at all levels. The maturity grid approach has been proposed by Maier (2006)

for product development organizations as a stand alone assessment tool. Actions to improve areas that are found to be deficient requires of support from other tools.
Awareness
Factor A B C D Currant Desrad
Sequence Most of us hav ovd r , Wr In1 arn k, w t [ of tasks No ?tgrt 4 Of tk do in ' the et a i is "tr g ao
in process seAluens it conrlinausy -- ---- --- - -------
---- - - - - -
We e arei partedily aware af People N aost of us hauoes eir~ouriel who should do wtAat andolve uhor-• I overview of who does wvhrat when and cotnuOcitistyy
involved rt ,,; ac I are i-v( and vity assess and adapt its
hc alt knuv Io na lo do Information The pr acss is dear ir ine fMost of us know in theory when, do it reguady, andN t tnugt o pioxedkes but not in what to do wen tut o noft continuously rrprove [ [ i
flOW practice do i regulady adequacy of infomation
Charnges are convouricated Code we mrnr y fid out by arsking Changes are voluntarily regkrly aid we are all well
Changes e lenj tens cam otlnicater. Pre ared thvoug contnuous optimisation
Changes are comsmiruicaed Organlsational NoW ti y ind out by asnry Changes are volutinily regd ary AHd We are all well [ [
changesg were l ade conraunicated prepared thrxwgh continuous optrrmisal n
Figure 4-3 Awareness sheet of the communication grid (Maier, Eckert, & Clarkson, 2006)
Evaluation of an initial state and an end state can be achieved by using the maturity grid approach. The inputs to both the initial and end state are derived from interviewing the organization, an example of the sheet used to record these changes is shown in Figure 4-3. The subjectivity of this method is greater than that of DSM and is also disarticulated from the product. In product development organizations having good models to link the reality of the technical difficulties to the organization and process is key (Browning, Frike, & Negele, 2006) and in this sense a maturity grid approach does not clearly support such an objective.
The maturity grid method does, however, help organizations identify areas of opportunity by allowing quick evaluation (1 day) of current and future communication needs. It is also convenient that it provides and insiders perspective on communication and avoids pushing the company in directions that are not well aligned with its work culture (Maier, Eckert, & Clarkson, 2006). Demonstration of this method has been carried out and successful results reported. Implementation of this method is also relatively easy as addition of communication as a question and measurable to current work satisfaction questionnaires would suffice.
4.5.2 Improving Communication
It is important to promote awareness in the organization that few things will be as highly regarded as good communication. Engineers in many organizations live in fear of the retributions that bad news will bring upon them, and will act out of fear by engaging in practices such as "never reveal you have a problem until you have a solution" (Repenning & Sterman, 2001). Working under this banner, defects and errors can go unnoticed for long periods of time and will only get flagged later

in the project when the effects become severally magnified. The building of trust in the organization is a long process that must eventually become part of the culture. Actions, direct and indirect, targeted at rewarding communication can have a profound impact on the speed with which we manage to develop a culture of communication.
Communication improvement methods must be tailored for each organization and address the specific cultural traits of the group under consideration (Katz, 1982). Three environmental aspects that can improve communication and one tool are presented, all of which must be applied knowing that subtle differences from one group to the next must be considered for effective usage.
42-1 Phsica l a
The influence of physical location of engineering teams and the effect of architecture is a subject that has been pioneered and studied in depth by Thomas Allen of the Massachusetts Institute of Technology. The findings made by Allen, and other subsequent researchers, have shown the importance of pairing the location of engineers and their communication needs.
As described in section 5.1, Allen identifies three types of communication: coordination [type I], organization [type II] and inspiration [type III]. In product development, inspiration communication is the most difficult to promote, followed by organization and coordination. Because Type III communication can only be influenced by physical location adjacency decisions should be made on the basis of Type III needs first then Types II and I. Type III communication will not happen unless people "accidentally" come into contact with one another. What we are doing is managing these "accidents," using the physical location of workstations and traffic patterns to increase the likelihood of a potential payoff. There is a greater need for current information driving Type II, so it is less dependent upon accidental encounters. While Type I communication is normally used as the basis for determining adjacencies in most organizations, R&D organizations are different in that they have a much greater need for communication of Types II and Ill. In most organizations, the criterion is efficiency. Interdependent groups or individuals are located near one another in order to minimize travel time, thereby increasing efficiency. In R&D organizations, effectiveness is more important than efficiency. In order to enhance effectiveness, some of the efficiency associated with Type I communication must sometimes be sacrificed in order to increase the probability of Types II and III occurring. Highly interdependent pairs of groups or individuals can be situated farther apart if necessary, in order to locate pairs that would benefit from Type II or especially Type III communication. This loss of efficiency has been labeled "functional inconvenience" because it can increase organizational effectiveness by making some things a little more inconvenient. The concept of "functional inconvenience" also operates in those situations where conference rooms or laboratories are located farther away from office areas in order to influence travel patterns in a building. Physical location is one of the easiest ways to promote communication.

4.5r.2.2 Culuir&
The organizational culture has an enormous impact on communication, and is the result of aggregating all elements of the group.
Groups strive to structure their work environments to reduce the amount of stress they must face by directing their activities towards a more workable and predictable level of certainty and clarity. (Katz, 1982)
As described by Katz, groups will tend to reduce the stress inherent in their workplace and because of this will seek ways to communicate in manners that reduce their uncertainty. Because of this even though the team members may be aware of how to communicate in many occasions what is professed to be the intentions for communication turn out not the regular practice in the office. This is often the result of environmental factors that surround us at the time (Bromage, 1970). As such an adequate environment is not only conducive, but necessary to good communication.
The culture that managers drive into the organization must stress the value of communicating problems early, with clarity and directness. A management that is open to acknowledge that surfacing development issues quickly is a merit and does not equate to poor work quality helps create the confidence for these interactions to occur.
One must carefully consider the social context in which project activities are being carried out in order to understand more fully how group members define and interpret their work experiences and to gain a more complete picture of group behavior. (Katz, 1982)
The differences in local culture (country, state, hierarchical level) must be considered to enhance communication. As an example, what may seem small or irrelevant comments in one culture can in others completely destroy the communication links in another. Clarity and understanding in group differences from the top down becomes therefore critical and aids to create teams that communicate without fear.
External communication is a function of the team's and individual's belief that they are knowledgeable about the external world and its impact on their work (Katz, 1982). There are several reasons why people can come to have increased confidence in their understanding of their surroundings. It is proposed that there are two main causes for this kind of behavior, both at opposite ends of the knowledge and experience axis. On one end, inexperienced engineers can be completely oblivious that there is something outside the world they have been presented with, being completely absorbed in understanding the knowledge that is available within the company. On the other extreme, experienced team members or teams that have been together for extended periods of time can come to believe that there is nothing new for them to learn from the outside

world. In product development activities both are dangerous situations, leading to isolation of the
development effort from the true market needs.
i *
o 9
0 2 4 6 8 Mean Tenure of Team Members (Years)
Figure 4-4 Project performance as a function of team tenure (Allen T. J., 2006)
'It is the tenure in the project team and not age or organizational tenure that is more likely to influence project performance.' (Katz, 1982)
Although the effect of having a variety of tenures from different team members on team
performance has not been sufficiently explored, it can be said that, in general, diversity helps enable the creative process. Keeping track of a team's tenure is easily doable, and can quickly provide a way to increase the team's communication and the performance of the project.
QFD is a management technique that has been proven to enhance intra-functional communication (Griffin & Hauser, 1992). As developed, QFD consists of four 'houses' that integrate the informational needs of marketing, engineering, manufacturing and management; of the four the
core house of quality is the more popular one. The 'houses' are essentially matrices that relate voice
of the customer to design attributes, then to part characteristics, manufacturing processes and finally to the production line. For a detailed discussion on QFD see Hauser and Clausing (The House of Quality, 1988). Completing the set of four houses forces the team to work together from the start of the project and promotes high quality well structured communication throughout the entire process and organization.
In their study of phase staged product development versus QFD product development Griffin et al. (1992) proved that when using QFD the core team would increase the overall level of communication. In addition to this, communication within functions and between functions increased while the communication with management was slightly reduced.

4.6 Key Takeaways - Communication in Product Development
Communication is a critical success factor in design. It can be seen as the social and cognitive process by which information is selected, messages are exchanged between interacting partners, and meaning is created. (Maier, Eckert, & Clarkson, 2006)
Throughout this chapter we have stressed the importance that effective communication has on product development. Many different lessons on how to improve communication have been reviewed and the following list summarizes key takeaways.
1. Efficient high quality communication is dependant on variables that are intrinsic to the culture, the organization and the project.
All the variables listed below are particularly relevant for product development organizations that exhibit the following characteristics: work is done primarily in multidisciplinary teams that can be geographically disperse, the final product is consumer ready, most of the work is to apply on existing knowledge and solutions, project length is short (<30 months on average). For each of the variables, we have marked those that are traditionally under the control of an organization's management by appending a 'UMC' (under management control) at the end.
Cultural variables that affect communication
* Hierarchical norms * Value of social communication * Inherent process discipline
Organization specific variables
* Organizational size * Incentive structure (UMC) * Hierarchical team structure (UMC) * Location of team and distance amongst team members (UMC) Project specific * Nature of the message * Rate of change in technology * Uncertainty in the project * Impedance that exists between parties
It is important to note that although there are many variables that are not traditionally under the control of management, they can be modified by good leaders.

2. Organizations must select the right communication medium and forum for each exchange and execute each with care.
* Design reviews must focus on becoming productive work forums for product development teams, instead of being only presentation forums
* Oral communication and face to face interaction can not be underestimated for daily interactions and problem resolution, and should be incentivized where possible
* Written communication must be clear and avoid being non-committal; it is key to ensure that important decisions get communicated in written format
3. Managing communication is a key aspect of an organization's leadership work.
The following is a list of some of the aspects of communication that leaders should be aware of.
* How we obtain information is as important as the information we obtain * Communication is not free and therefore work must be done to increase the
added value in each interaction * With increased uncertainty communication becomes more important. * Communication should be frequent, early, two way, and rich * Great communication in an organization needs alignment of channel, message
and receiver
4. Gatekeepers help organizations improve their communication abilities when there is a high impedance amongst the teams or individuals that need to communicate.
Gatekeepers help organizations communicate with the outside world, providing a single point of contact that efficiently seeks information outside and is then capable of relaying it to the right person within the organization. The key characteristics of a gatekeeper are:
* Capable of bridging technical divides, has good core technical knowledge * Can interact with large numbers of people inside and outside of the organization * Correct organizational / hierarchical position
On the down side gatekeeper may also bring some undesirable characteristics, such as reduced communication bandwidth.
5. Peer to peer communication is very efficient when receiver and source have the same language (a low impedance).
Requirements for effective use of peer to peer communication are: high compatibility amongst parties (hierarchical, cultural, technical) and clarity on project direction.
6. Physical distance amongst team members significantly affects communication and team performance.
'The probability of frequent technical communication among engineers and scientists is determined by their locations in physical and organizational space.' (Allen, Architecture and Communication among Product Development Engineers, 2007)

By creating Obeya rooms and co-locating teams organizations can help create the right environment to incentivize increased communication.
7. Language differences that exist amongst the teams participating in product development must be managed.
The disparities that exist in the languages that the different departments speak must be controlled and aligned. Achieving this is important to achieving team integration and work.
* Engineers speak in terms of product features and specifications, and think about the product in terms of problem solving. (Griffin & Hauser, 1992)
* Marketers speak the language of the customer and are customer oriented in their approach to product problems. (Griffin & Hauser, 1992)
* Manufacturing speak of utilization rates and process specifications, and think about the product problem solving in terms of manufacturing feasibility.
Manufacturing and marketing provide inputs and receive outputs providing boundaries and end goals to the product development system, yet many times have severe difficulties communicating back and forth.
8. High performing product development teams exhibit common communication traits.
* Increased intra-functional and inter-functional communication and reduced managerial communication
* Increased time spent on communicating design related knowledge and less time expended on the reporting and planning activities
9. Quality of communication is as important as quantity. Increasing the quality of information exchanges helps product development organizations optimize their information exchanges and make the most out of them. High quality communication is characterized by driving organizations toward learning and increasing the knowledge and information available for making the right decisions in a timely manner. One of the proven ways to improve communication quality is to use experienced individuals (technical experts) to serve as 'smart filters' that help optimize communication.
10. Organizational alignment is a key enabler to communication
Having an organization that has an organizational structure that is congruent with the product being developed helps teams communicate optimally. By reviewing and clarifying organizational and product system boundaries, team leaders can help create this alignment in the organization. Additionally, in those instances where the organizational and product system boundaries can not be modified to become aligned team leaders can create teams to mange these interfaces.

These elements acquire increased value in the context of the product development architecture. In complementary manner the following three quotes from Katz can serve as guidelines to designing a product development system that promotes communication inherently.
'One of the main principles of human communication, often referred to as selective exposure (Rogers and Shoemaker, 1971) is the strong tendency for individuals to communicate with others who are most like themselves or who are most likely to agree with them.' (Katz, 1982)
There is a strong tendency for groups to establish certain stable structures of behaviors and relationships, simply because it keeps them feeling secure and confident in what they do. (Katz, 1982)
Group members that have been performing their jobs for extended periods of time are less likely to respond to the challenging aspects of their project activities. (Katz, 1982)

5 People and the Organization
In organizations individuals participate in the process without loosing individuality, but strive to reconcile their view with all other points of view relevant to the
situation (Huddle, Winter 1966, p. 12)
Organizations are a core element of society and have existed for thousands of years. Their number, however, saw great increase in the late nineteenth and twentieth centuries (Dunbar & Starbuck, 2006, p. 171) spurred initially by the industrial revolution, and then later by the shift to knowledge based economy. It was during this period - the industrial revolution - that it was first observed that
for a same task, under apparently equal circumstances, different organizations would perform either
better or worse than others without any apparent reason. This observation prompted an increased
interest in the role of organizations within society and how their contribution could be maximized.
Product development is necessarily a human activity; and the people taking part in this activity form and work in organizations, organizations that in turn have great influence over the performance of
new product development. Schedule, cost and quality (or product performance) are the three main variables that determine the overall performance of the product development activity. The ability to balance the three in the most effective manner is a key competitive advantage that the best product development teams brandish. Achieving this delicate balance requires every member of
the team to work in synchrony; with aligned goals, processes, product understanding and development tools. The synchronization, and alignment, that a good product development organization has, sets an objective we should all pursue.
In the product development organization teams of people, with different backgrounds and specialties, participate together to develop new products. The organizational and people aspect of the product development activity has received a lot of attention, and it is to some degree agreed that only environmental and process aspects surrounding product development can be directly managed by a projects leadership, in accord to this we will elaborate on both in the chapter. As previously discussed product development being a process that can't be fully mechanized (Browning, Fricke, & Negele, 2006) is largely influenced by the people involved in the execution of the tasks required to deliver a product. However to manage the human resource requires of the use of indirect actions. As such it is possible for a company to provide an environment that promotes individual behaviors that are associated with successful product development.
The relationships in a product development process arise amongst the different activities and not between the departments (Malone, Crowston, & Pentland, 1999). In the same way individuals organizations also tend to align themselves to activities and because of this it is advisable to define the organizational structure in a manner that is supportive of the process. There are however many times external factors that are out of our hands that may predetermine the structure of the organization in such a manner that direct support of the process is difficult. Being able to reconcile the process, the organization and needs of the individual can lead to significant organizational success, and helps avoid conflict between the organization, the individual and the process.

Thomas Allen and Gunter Henn in their book The Organization and Architecture of Innovation
describe business organizations to be social organizations that have needs on both organizational
and spatial levels (Allen & Henn, 2007). Both of the aspects mentioned, organizational and spatial, are of special interest because they lay under the area of influence of management. As such, changes in these areas are plausible and can have tremendous influence on how we can conduct our
product development activities. This has been proven in many occasions and within different social
and geographical contexts, which gives us reason to believe that understanding of these elements can be of great benefit.
One of the key human activities required to enable successful product development, as has been
described up to this point, is communication. It allows for team interaction that makes solving problems that would otherwise be insurmountable possible, while providing the means for
innovation and improved product development performance. In this regard the spatial level of the
organization - physical location and distance between people - has proven to be critical in the
amount of communication that takes place. The importance of the spatial needs of organizations can be seen in the examples such as BMW's Project House, designed specifically to promote interaction and communication in the product development teams by improving physical location.
The other parameter that Allen and Henn mention is the organizational one, where the main
elements are the managerial structure (dictated by the organization chart), the rules of interaction (product development process and company policies), incentive system, existing company culture and competence. All of these elements will be explained the chapter with the intent of providing a comprehensive overview of the organization and its role in product development.
5.1 Unique Aspects of the 'Organization' in Product Development
The organization in product development has some unique aspects that make it interesting to study, and difficult for managers to grasp. The structure of the organization has been a topic of wide
spread discussion and in engineering organizations the influence of structure has proven to be
critical to overall project success. In product development definition of the organizational structure model to be used depends highly on the characteristics of the product at hand. In addition to other elements, the structure is one of the elements that require attention during organizational design to
ensure that we do not create misalignments in our design. The three dimensions that dictate
organizational structure (Allen & Henn, The Organization and Architecture of Innovation, 2007, p. 43) can serve as guidelines to the organization and are further developed in the chapter:
1) Rate of technological development 2) Interdependencies in the product architecture 3) Project duration
An important consideration in designing a product development organizational structure is that all development activities have some level of inherent risk involved in them. The ability of the organization to manage risk appropriately has significant impact on the effectiveness the

organization to deliver the final product. Because risk exists for every piece of the product
development activity, having flexible risk capability (Dehoff & Loehr, Innovation Agility, 2007) enables PDOs (product development organizations) to embark on ambitious - risky - endeavors and deliver successfully. Flexible risk capability can be created by designing the right organizational
structure. In general for every project there must always be one person that is responsible for the overall management of risk for the project. A common ailment of organizations is that there will be a misalignment between the level of responsibility and the authority delegated. For example, it will
be clear who is responsible or accountable for failures - poor risk management - but seldom will
this person have the appropriate level of authority to improve team performance. It is critical that
there be a match between responsibility and authority in order to allow good risk management
within projects. The organization therefore must attempt to match the responsibility to the role.
5.1.1 Suppliers
Suppliers play a vital role in the product development organization. Currently most OEMs work with
a variety of suppliers that range from full service, to only part procurement. Suppliers that have full
service capability will have active roles in the design and engineering of new vehicles, and need to
become fully integrated to the product development organization. Suppliers involved only in the
procurement of parts, may not be involved in engineering, but need to be accounted for during every step of the development process if the finished product is to be successful.
In many ways suppliers are now extensions of the product development organization that must be carefully considered when designing a new organization. Extended enterprise is one of the ways in which Toyota has managed to capture the need to understand the whole value chain. Within
product development Toyota begins its relationship with what are to become long term suppliers by investing with them in the creation of innovation capability (Dehoff & Loehr, Innovation Agility, 2007). This ultimately results in Toyota being able to drive multiple innovation programs for their products in parallel due to the distributed responsibilities and an excellent understanding of the interfaces required to achieve system compatibility. This can only be done in the presence of an
organizational structure that supports active supplier involvement and allows for modularity in the development process.
Even in the case of suppliers that are responsible only for producing parts from blueprints, their integration to the overall development process is essential. As seen in many development problems, lack of good supplier integration to the base PDO (product development organization) causes sever issues when the time to solve unexpected problems arises. A common issue is the lack
of clarity in the OEM-supplier roles and responsibilities leading to difficult interactions and low p[performance results.
As a consequence, OEMs have moved in recent years towards consolidating supplier bases and to reduce the number of interactions they must manage. This helps develop long lasting relationships between suppliers and OEMs, helping them both improve their competitiveness the market.

5.1.2 Globalized Product Development
Today's automotive companies compete in a global market place, and as a result product development organizations must become decentralized. Several factors have lead most OEMs to develop their vehicles at different locations around the world.
1. Local needs - not all countries have the same product needs, and true customer knowledge is available only directly on site
2. Manufacturing location - cost of manufacturing and logistics determines optimum location of plant and having product development facilities near by makes for more cost effective interactions
3. Engineering labor costs - costs of labor is not equal at all locations, aggressive cost reduction has moved some engineering tasks to low cost countries
4. Specialized knowledge - even though economic reasons may indicate moving most product development to low cost countries, knowledge asymmetries drive companies to retain sites at more expensive locations
5. Heritage - cost of moving facilities, cultural heritage and other societal factors make distributed product development a reality
In combination, these five factors determine the degree of decentralization of product development and global engineering each OEM has decided on. Having product development located at different locations around the globe may have positive economic effects for some OEMs, but the product development process must be adapted to work in this new environment. Communication, coordination, language, time differences, distance and cultural barriers must be mitigated for success.
In many ways having a decentralized product development organization is comparable to what happens when OEMs work with full service suppliers (provide engineering and parts). In this sense it becomes important that the rules of interaction are clarified with the utmost precision and that the process followed by all parts be common. This last item is of special importance to allow for good coordination of the team, and seamless work in distributed teams.
The manner in which the organization is designed must flow form the need for decentralized product development. Because what will be needed is coordination amongst the participating parties, the organizational structure must be such that all involved parties have a single product development head that can make trade off decisions for the overall product development process. Alignment of the functional areas also becomes important to allow for efficient knowledge transfer amongst different locations of the same specialty around the world, and intuitive work with communities of engineers who may only be a voice on the other side of the phone in many development programs.

5.2 The Role of Leaders in Product Development
An organizations leader is mainly concerned with what is known as environmental affairs which
encompass the relationships, conventions and opportunities that encourage or discourage talented
people from contributing to the organization. Within this understanding, one important daily task for leaders is therefore communication, and more centrally, listening and explaining (Shapiro, Fall 1984). The leaders' task can thus be also seen as that of designing, developing and maintaining the organization with the purpose of maximizing its throughput.
The nuances of how a leader interacts with his team, the structure that is selected and how the
tensions are managed are critical to success. This is true for example in that although management does not always take the leadership role within organizations, in theory it should be so, and every effort should be made to align actual and desired leadership location.
Leadership is critical for product development organizations, and research studies in a variety of industries have proven that there is always a strong link between upper management levels and their respective subordinates (Sterman, Repenning, & Kofman, 1997, p. 519). Thus, there is significant responsibility on mangers to provide clear direction to their subordinates and create an ambience of trust and true leadership that promotes growth and learning in the organization (Adler, Goldoftas, & Levine, 1999).
To address leadership in organizations we will look at the role leaders can take in product development and compare the two options: system designer or process manager. We will then review three levers or aspects of an organization that a leader can use to improve the performance of the organization. Lastly a short comment on 'vision' as a manner of giving product development projects direction is presented.
5.2.1 Technical Project Leader: System Designer or Process Manager
One of the most important leadership figures within product development is the project leader. In different organizations this individual takes on different names; one that is surely familiar is that of 'Shusa' which is the name used by Toyota to designate project mangers, equivalent to the Chief Engineer at North American Car. Although most companies will have some equivalent of this figure on their organizational chart, project leaders can assume their role in very different manners and achieve with equally diverging degrees of success. For the automotive industry, comparisons made between Japanese OEMs, Toyota in particular, and North American OEMs has identified two main roles that project leaders tend to gravitate towards (Morgan J., 2002).
* System designer (Toyota) * Process manager (North American OEMs)
Use of a system designer or process manager is the result of many organizational factors. Toyota drives the use of 'Shusa' as a system designer and overall project lead, almost as their organizational

hub within engineering. Process, product, functional organization and individual engineers support the existence of a leader that is a system designer and engineering lead. In the same manner, the process manager role is supported, and needed, by the organization in North American OEMs. Because of this migration from one role to another requires of significant effort on behalf of the whole organization and executive support.
From the organizational point of view, it has been seen that project mangers are more effective when the can assume the role of system designers. Individuals that assume this role within their organizations can exert significant pressure on the team and drive for project results with much more ease that process mangers. Good implementation of the system designer model, requires that the project leader be an engineering integrator and system designer, while separating the process management and tracking. The process management is a separate function, not one that is unknown to or unimportant to the project leader; but one that he need not manage in detail. This separation allows the project manger and leader to concentrate his efforts on system interactions and engineering and leaves milestone tracking and timing to a separate organizational entity.
One aspect of the organization structure that is intimately linked to the process manager or system designer dilemma is how the organizations is designed to respond to decision making. Decision making can be driven by both cultural factors and the hierarchical model adopted in the organization. It is clear that some organizations tend to lean towards having a single person decide most aspects for a program, and that others summon a committee. The system designer role is an excellent example of an organization that depends on a single leader to drive a project and make all of the significant tradeoffs.
Most North American companies have been shown to depend more highly on committee type decisions. These can have advantage in presumably better balancing the needs of all the people involved, but they can also consume vast amounts of resources and drive set of incoherent decisions for different subsystems. Committees need not be formal to have a profound effect on decision making. However the lack of formality does blind the organization from identifying a potential source of inefficiency and further dilutes accountability.
Using a chief engineer that is a system designer makes accountability for program performance easier to identify, and allows teams to make decisions faster. Many organizations have shown that this model is effective at making trade offs and technical decisions when there is adequate customer focus and definition. In addition to this, good system designers will in reality make decisions by gathering all relevant information, quickly creating consensus amongst team members and then aggressively pursuing the agreed upon direction. Good system designers are difficult to come by, and it is a competence that an organization must grow over many years. Because of this, although having a top heavy technical leader can be beneficial to program performance, implementation may not be possible immediately within many organizations.

5.2.2 Levers for Organizational Change
There are many apparent mechanisms that managers can use to change an organizations behavior
and performance. However one can summarize most of them using three categories (Fricke, 2007), these are:
* Organizational structure * Organizational competence * Organizational culture
The three categories are inherently different and pinpoint different aspects of the mangers job. The structure is the master design and theory of how things should work, and how the organization
interacts with the process that is followed, its products and the customers and suppliers. It makes
assumptions on the interactions that the organization will follow and assumes limits to the reach of
the organization. The structure of the organization, can be also seen, as the environment in which
the people will fit and the organization will develop. Good structures will not only allow individuals
to perform at their best, but will facilitate interactions amongst members that will result in superior
organizational performance.
The competence of the organization is given by the potential to accomplish work that an
organization acquires through its people. Hiring, training and experience all play important roles in
increasing an organizations potential. For product development the competence can therefore be
understood as the technical capability of the individuals that conform the organization. Selective
and wise combination of the right people can multiply their individual competence and significantly
increase the organizations potential. However, an important remark regarding an organization's
competence must be made. Although competence may be theoretically increased through training,
capability may only be demonstrated through execution. This distinction is key for a variety of
reasons, but most importantly because for growing organizations only by executing will the
organization truly achieve increased capability and demonstrate its competence.
Levers Tools Area of influence
-ir~ - -- -- -- - R 1I~
Hirra MI
i Stuctre eporingStrctur Eniro men
-t 01 I Figure 5-1 Levers and tools for leading organizations
r tnta

The culture is the intangible set of assumptions that the organization shares that determines their perceptions, thoughts and feelings (Schein, Fall 1996). As such, the culture determines the overall behavior of the organization and provides each organization with a unique character. Culture in an organization is the result of complex social interactions that are influenced by factors that range from the nationality of the individuals, to the year end bonus system used to incentivize performance. However, mangers can use a few tools at their direct disposition to help them create the culture they seek; some of these are: the incentive system, respect, trust, leading by example.
The summary of how these three levers work together, the tools available for moving them and their area of influence is presented in Figure 5-1. In general structure and competence are less vague than culture, however the three must work together to help organizations reach their goals. Culture, being less specific, can become difficult to see as a lever, however mangers must come to the understanding that not identifying culture as a key aspect of their organizations success can weaken any transformation plan, no matter how good the individuals and their environment.
52.2.1 Roles and Respobiltires
Roles and responsibilities have the power to shape relationships within the work environment in much more an efficient manner than other available mechanisms. Changing roles and responsibilities modifies elements of structure and culture in an organization. Roles and the responsibilities are many times grouped as a single item, however the research conducted in has shown that they are two separate concepts. By separating them some of the conflicts that exist in defining team and their work can find solution.
The research conducted shows that US and German product development organizations are significantly difference in how they approach definition of roles and responsibilities. In Germany specification of roles is done in great detail and clear definition between functional groups exists. Responsibilities however overlap, sharing for example a team goal to deliver a new vehicle on time and within cost. The model in Germany can be approximated to example 'c' in Figure 5-2.
a) b)c)
Figure 5-2 Roles and responsibilities
On the other hand the US the model is more akin to either option 'a' or 'b'. In some cases ('a') the both roles and responsibilities never overlap, making delivery of team goals very difficult. Responsibility for delivery of a finished design falls into a white space, leading to situations where certain aspects of the vehicle seem to be no ones priority. Other examples, similar to 'b' in nature,

lead to inefficiencies born from duplicate roles. In some cases when this is poorly managed the duplication of roles will also lead to areas of the design that no one is working on.
Based on these observations, it is concluded that the German model for approaching roles and responsibilities improved overall accountability. By improving accountability the German model also reduced the amount of tracking required for the engineering team and improved their ability to deliver team results. A final advantage of this model was the increased efficiency with which human resources could be used.
5.2.3 The Vision - A desired state
There has been a variety of arguments in regards to the importance, or not, of developing a vision for an organization. Some have argued that they are critical and extensive papers and books have been written to help managers and leaders set the right vision. Others have keyed down the importance of setting a vision and focused on setting up the right team. What is certainly agreed to, however, is that all leaders must help the organization define its direction. Whether we care to call this direction a vision, or prefer to call it a consensus becomes then less important; but it is critical that the leader be able to give clarity of purpose and direction.
In product development the concept of the project, is the vision. System designers that do not have the capacity to hear customers needs for the product and convey this direction to the engineering team will not succeed at product development. Good project management is essential to product development, but without a direction it is meaningless, and because of this in the automotive business having a 'car guy' (Sobek, 1997) at the helm of automotive projects can be a recipe for success.
5.3 The Individual - Building Block of the Organization
The unit element of all organizations is the individual. Hence, successful organizations must make sure that they have the best possible people at their foundation.
'Designers contribute to finding solutions and developing products in a very specific way. They carry a heavy responsibility since their ideas, knowledge and skills determine in a decisive way the technical, economic and ecological properties of the product' - (Pahl & Beitz, 2007)
Product development, being a human activity that requires engineering, imposes stringent requirements upon its individual members. The final product is the result of translating the customer needs into a design, and this is accomplished by making a series of many decisions that in conjunction make the product. Every person within the product development team has influence over some or many of these decisions, and as a consequence impacts the success of the overall project. Organizations can choose to dismiss the importance of the individual within the organization, and attempt to mechanize the product development process. Doing so, has however,

proven to be almost impossible to accomplish and resulted in poorer project performance. It is
therefore better to embrace the individual as the fundamental building block for an organization
and thrive on the desires, goals and capabilities of each.
Actions at the Individual level Resultsfor the Organization
--
I t ",) I I
--
I
-
I--
Culurebaed ~n hebelefsan
e p ttinso tev.,h l og~nz.t()*
Knweg ndtcrc lcpblt ~~1~11111ncred,'e~
Figure 5-3 Link of individual actions to organizational results
5.3.1 Hiring
What individuals bring to the firm is as important as what they develop on the job. Hiring is a unique moment and opportunity for an organization; it allows infusion of new thoughts, perspectives and energy allowing the organization to stay fresh. It is also is also the point in time at which much of the intrinsic direction and culture of the organization will be defined.
The organization must align its overall objectives with the requirements of new hires. People bring along intrinsic needs, potential and opportunities that must be assessed to make a good match with the organization. Some aspects of people are more difficult to develop after hiring than others, and choosing what the focus of the organization will be is important for successful growth. So important is hiring the right people, that pressure to grow an organization must never prevail over the search for the right talent and individuals.
Being able to identify what the desired traits in new hires are can be as important as attracting people that have them. In defining the desired characteristics of people for an organization, there is always danger that in selecting a series of traits for potential new hires one will lose diversity. This must be weighed against the importance of having the right people aligned with our organization. For product development there is in many occasions a need to focus on acquiring technical talent in order to grow the organizations capability. The trade off between technical competence and intrapersonal skills is one that must be done often; and a variety of examples have shown that
-
0tl(E
Retntin -of ig
poleltra

technical expertise is preferable in many occasions, and that management must focus on seeking those exceptional cases that achieve a delicate balance of technical and personal skills.
Some organizations, such as management consulting firms, rely more explicitly on their hiring ability to succeed than do others. Having personally gone through the selection and hiring process of
management consulting, and reviewed in detail their strategy as an outsider, lessons can be learnt
from these fast recruiters that can be applied to other industries. One of the aspects that is quickly, but not obviously apparent, is that management consulting firms seem to follow the 80-20 rule
when it comes to hiring. For the most part (their 80%) they focus on recruiting people with a basic skill set that will be put to work immediately. These are generally either MBAs or undergraduates, that at two different levels of execution can be immediately be put to work on the bulk of the day to
day activities of the firm. These people form the bulk of the work force and some may eventually
proceed to higher management positions, but most will never move to far up, and leave the
company in a relative short time. For this kind of hiring there are specific characteristics and
knowledge that the interviewers look for, along with some personality traits that will allow for
successful integration with the organization. For the remaining 20%, management consulting firms
hire individuals with specialized knowledge in different areas, and spend significant more time
choosing these individuals and designing their possible positions within the company.
In separating mass hiring from specialized knowledge individuals, consulting firms ensure that an
adequate balance is maintained and all their needs are met. Within product development organizations, there is also a bulk of work that must be completed and this requires people that
have a basic set of technical and social skills. In addition the organization needs people with
specialized knowledge and others that can take the role of future leaders. Making sure that we hire
with care from both pools of people makes hiring more efficient, and creates the space needed for
the best people to develop.
5.3.2 Initial Development of People within the Organization
In all social groups initial assumptions, and the social connections that these create, become some
of the most important organizational links; eventually maturing and becoming a culture. The
induction to an organization has long lasting effects on people and may well be one of the best
opportunities to begin developing the desired organizational culture.
Initial development must focus on the following:
* Providing a clear vision of how the organization works and what the position of the individual within it will be
* Clarify where the organization stands at that point in time and what the future expectations are
* Embed the key organizational values and principles * Provide documentation of key resources

Within North American Car in Mexico, all initial hires go through a specific induction program that has the intention of providing the new members of the community with a good sense of what NAC is. The program has been developed to integrate all major areas of the Company is a tour/class that lasts a few weeks. After the initial introduction, practice has been to locate new engineers in jobs that allow for hands on work to provide rapid learning. Success of this method has been demonstrated, both at NAC and by similar programs in other OEMs. However, there is still a need to increase the development of organizational values and principles in the initial days after joining the company, and little information is available in this regard.
5.3.3 Talent Retention
Product development requires of people having experience, and the retention of the best talent. Gaining long term commitment is an essential part of the overall strategy of developing people, without good retention, efforts to hire the best, develop their capabilities and move them in to management are without fruit. Some of the key elements that have been identified as supporting long term commitment are:
* Challenging work * Attractive compensation * Personal and professional growth opportunities * Stable and rewarding work environment
The development of long term talent is one of the core capabilities that some of the most successful product development organizations have long recognized to be core and have actively developed (Dehoff & Loehr, Innovation Agility, 2007). Making it happen, though, is a delicate tug and push act that requires of personal tact and organized process in tandem.
One of the often overlooked items of retention is the incentives given to supervisors and managers, to work on keeping their best people within the organization. An example of this situation was seen a few years back in North American Car, and was recently used as a learning experience to redesign incentive and retention programs. NAC sponsors a high performance education program that takes some of its best engineers and trains them in broader engineering and management topics to prepare them for supervisory and future management roles. However, retaining these people has always been somewhat of an issue. Initially the strategy was to make all participants sign a two year contract that bound them to work at NAC after the educational program for an additional two years with the expectation that this would increase the amount of people that would eventually stay in the company. This proved not to work out, as it created the wrong incentives at the management and supervisory levels. Because the engineers were coming back from a high visibility program and signed contracts avoided them from Leaving before tow years, there was little to no incentive for supervisors to deal out the best jobs to these now better prepared engineers, or consider them for promotion. Instead it became easy to freeze some of these peoples progress, causing great unhappiness in the employee and resulting finally in their leaving the company.

5.4 Designing the Organization
Mangers are continually confronted with the need to increase the productivity of their organizations. Almost any organizational change done with this purpose will ultimately also require a fundamental redesign of the existing organization in order to better accomplish the task at hand. As such we will define organization design as any explicit effort to improve an organization (Dunbar & Starbuck, 2006), and will focus in this section on primarily on the people related aspects of organizational design.
In this section we will focus the discussion around structure, competence and culture; the three levers that we have proposed managers can use and that have been introduced in the previous section. These will be presented along with examples of real world design examples that have been seen to allow for quick development times. Three examples were studied and will be presented: the Ford NASCAR team (interviews), automotive product development organizations in Germany (interviews) and Toyota product development (literature). Ford Motor Racing was recently highly successful within the NASCAR (National Association for Stock Car Auto Racing) series, and interviews with project mangers for the Ford NASCAR team where conducted to glean lessons on organizational structure. The Ford NASCAR team presents a good candidate for evaluation given that the team has recently designed its organization to great success after it took a thirty eight year rest from the NASCAR series. Success of this organization is clear in the finish line results obtained with the 2006 Fusion (Ford Motor Company). The German product development organization of North American Car as well as the automotive development branch of the University of Achen, also presented unique opportunities and insights under the lens of a different culture. Last, Toyota has been referenced given the almost universal agreement today that their product development system is largely responsible for their current success in the automotive industry.
5.4.1 Definition of the Organizational Structure
The selection of an organizational structure is not a static event, but rather a dynamic one that we must continually manage and redefine. Changes in organization structure must be done slowly and with caution to avoid generating uncertainty in the organization. Today, most product development teams in the automotive business are organized around some variant of the matrix organization to cope with the requirements of the development process (Morgan J., 2002)(Sobek, 1997). Allen has described the basic dilemma around matrix organizations to be focused around the decision of forming an organization with either a project or functional skew.
Department: Aligns the organization to the company's technologies. Allows better control of the core technologies, and improves technical support to the ongoing project for specific technical issues. The cost and effort of project coordination is higher.

Project: Organizations aligns more closely to the project at hand. Basic organizational structure is a team formed of individuals from different disciplines that report to a same manger, who is in turn responsible for delivering a project. Coordination of project is thus easier. Separation of technology and project is costly and eventually erodes the company's technological base.
As can be seen in this quick comparison of extreme department, to extreme project oriented organizations, both have pros and cons. Mangers naturally want to have the best of both worlds, and quickly set out to attempt the creation of a 'balanced' matrix organization where the importance of both project and functional sides is at an equilibrium. This is however difficult to achieve in practice, and will normally result in an eventual shift to either a project or functional biased organization.
If this is the case then it becomes more fruitful to select a bias that is well suited to our organization, instead of waiting for the shift to happen without our control. One element at the disposal of mangers to make this choice is the rate of technological development, which although is not normally one of the variables considered in selecting the organizational setup, proves to be extremely valuable in practice. Organizations where technology is changing at a faster rate are better off having a functional bias, while slower or more mature industries will align better to project organizations. In the automotive industry Toyota has proven that using a matrix where the heavy weight manger is on the project side has benefits in product development performance.
Some common mistakes that must not be made when selecting the matrix bias are the following. Important project work interdependencies should not be ignored in designing the organization to separation of important areas that need interaction continually (Allen T. J., 2006). Regarding project duration, mangers tend to put far too much importance on this parameter when choosing the desired setup; experience has shown that focus on activity duration will normally lead managers in the wrong direction.
It is suggested that the organizations setup be tested by identifying the ease with which our customer's needs and requirements will flow through the development process and into a final product. Ability to retain need integrity greatly increases the odds of success for any given product.
Research conducted for this thesis has identified poor accountability as one of the major sources of organizational dysfunction for product development. The complexity of developing a new car and the multiple interfaces that are generated create areas where more than one individual and work group could be responsible for delivery. Identification of the responsible party becomes a political problem and drive the organization away from what is important; delivering a good product.
The organizational structure can have a significant influence on how accountability is managed and felt throughout the organization. It has been observed that both the extremes, absolute lack or organization and over definition of the organization, can lead to poor accountability. Evaluation of

the NAC product development team in Germany suggests that an organization that tends towards
over definition of roles and that additionally stresses product responsibility as a team deliverable is highly effective in the automotive industry.
Organizations should aim to be structured to clarify purpose and support generation of accountability and the individual level. This is critical given that a vast majority of the development decisions are made by individuals that must remain accountable. Accountability at the individual level helps development teams mange complex trade off situations and keeps issue cascading down to a minimum.
5.4.2 Culture definition and design
The term culture has been widely used to name a set of loose characteristics that identify a group of people. Use of the word culture to denote characteristics that promote or subdue the effects of organizational change have been debated by product development practitioners and academics. It is however accepted, on a more or less wide base, that different 'cultures' present different challenges and that actions can be taken to modify an organizations culture. A good definition of culture for the purpose of organizational design is provided by Edgar Schein:
A culture is a set of basic tacit assumptions about how the world is and ought to be that a group of people share and that determines their perceptions, thoughts, feelings, and, to some degree, their overt behavior. (Schein, Fall 1996)
As stated here it is assumptions that ultimately determine the culture of an organization, and as such should be the focus of management when attempting to change the culture in an organization. In some ways these shared assumptions can also be viewed as 'traits' that define how an organization acts and define its personality.
The word 'traits' has been more broadly associated with evolutionary characteristic in animals and plants. For some time humans have been aware that traits have a profound impact on the ability of living beings to survive or perish as was demonstrated by Darwin. Because traits are inherited and become characteristics of different populations we suggest that key organizational characteristics that are common to all members be referred to as traits. In doing so we can also say that these traits are characteristics that can be selectively chosen and developed in an organization to enhance its performance. And that left alone individuals in the organization will select the traits that favor their survival as they best see fit; this may or may not align with the survival of the organization.
Organizations can both thrive and die on the stereotypes that are created around them. In some cases, like with Japanese and German organizations, there is a sense by people outside these organizations that the traits, and therefore the culture, they poses can not be replicated elsewhere. In the mind of these people these 'cultural differences' impede themselves and others from being as good as the Japanese and Germans are at product development (Repenning & Sterman, 2001). This has however been proven to be an error, and one that is extremely costly to organizations. Culture

is an organizational asset that can be developed, not a characteristic that is set in stone for ever. Even Japanese, with their hundreds of years of rigid hierarchical respect have found that all too quickly culture these norms will fall apart without constant reinforcement.
Attributing a trait or characteristic to a group of people has a ripple effect over all the activities they perform. This effect can be positive or negative, but in either case they are difficult to manage as they quickly become part of the corporate culture or even of the national culture. Because of this a
growing organization must focus on ensuring that the people that work within it are clear on what distinguishes them from other cultures in a positive manner. This will support the growth and further development of positive traits that will become a signature mark of everything the organization touches. It is of critical importance that organizations develop and nurture these common traits among their employees. The traits become amalgamated with the goals and ambitions of each individual, and in doing so become more robust to change ensuring that the human resource is maximized. An example of this idea at work is present within 'Toyota [that] relies not on positional authority and compliance but on its culture - shared goal of program success instilled broadly through the enterprise - to make it all work.' (Dehoff & Loehr, Innovation Agility, 2007).
There is no question that some of the traits that organizations present, are easier to develop in some countries than they are in others. Each individual comes to the company with a set of values and assumptions, which from day one begin to forge his understanding of the organizations culture. In the same manner the individual helps form and change the culture of the organization with the traits she or he brings along from the outside. Because of these two factors we must be careful to hire the right people and use the naturally occurring tendencies by country to build our organizations culture.
It has long been said that a lot of the success of Toyota lies in its culture. Toyota has managed both to develop this culture and then, only recently, capture it in a Toyota Way handbook that can now be used to cascade the Toyota Way to all new employees around the world. Amongst the characteristics that have been observed to distinguish the Toyota culture are: personal accountability, continuous improvement, collaboration and elimination of waste. (Dehoff & Loehr, Innovation Agility, 2007)
The importance of an organizations culture may sometimes be underestimated. Under the normal operating conditions most product development processes and systems work without major glitches, it is under strain that failures in these systems occur. External factors, such as increased competition in the market or unfavorable economic conditions, can trigger these failures and can quickly lead to vicious loops within the organization that prevent it from recovering. It is under harsh conditions that the importance of team and culture become imperative. Personal conviction and shared goals become vital; these soon show up as the differentiating factors between teams and companies that either succumb or survive tough situations. Any attempt to improve without having broken the cycle of self confirming attributions (Repenning & Sterman, 2001) will be futile with the wrong culture, as all are efforts will feed a our vicious cycle. In the same manner if we

manage to break the loop and change the culutre, or better yet begin a design our culture, any number of the available processes, tools and improvements will have a tremendous positive impact on the organization.
As an example of the importance of culture in organizations we can look at how a culture of perfect engineering and implementation drives NASCAR teams to win on Sundays. Interviews with mangers of the Ford NASCAR team highlighted the importance of their own internal culture and commitment to success at the racetrack. Over the years racing teams have become used to working under great pressure and able to deliver repeatedly each weekend to win championships. To accomplish this every member of the organization must execute their task to perfection, race teams have little to no excess of personnel so each individual must be able to carry their own weight. As an example of how tough the environment can be, a few years back during testing an engineer left the differential oil drainage plug loose and the car slipped on leaking oil after a couple of laps and hit the wall. There was no asking what had happened, the engineer was removed from the team even before the car remains had been removed from the track. No one on the team was surprised by this, they understood that everyone was directly accountable for their actions.
At the same time, however, the interviews brought out a profound sense of belonging on behalf of the team members that made them work together under seemingly impossible conditions. Each member would help in the case someone was missing and all members were invited to chime in on what ever matter they saw fit. Both actions were done responsibly; lending a hand and assuming responsibility, and speaking up when constructive input was possible. All in all the culture within the NASCAR team was exemplar. It was the sum of individual aspirations, team goals and spirit, heightened sense of responsibility and clarity of purpose. Within this culture, change and high performance are not only possible, but almost a given.
As we have seen we must integrate and embrace the challenge that dealing with organizational culture poses for us. We must also take the lead and define how we want our organization to develop, taking clear actions towards steering the organization in that direction.
5,2.1 oca ld ' . 1im-nent atii their influence on organizational cuiltre
An interesting addendum to organizational culture was provided as a clear insight by a North American Car director with extensive global product development experience. For this purpose we will present a short summary on his insight, especially in the view that little literature was found on this specific subject.
Characteristics associated with the country in which engineering organizations grow and their social, economic, architectural and in general all environmental characteristics have an important impact on the products created. Experience working around the world showed that countries where there has been scarcity are more akin to caring about cost, than those where there is less awareness of the limited availability of resources we must deal with. Such is the case for example of both eastern Germany and Japan, which for many years after WWII lived in scarcity of resources. The people in

these countries learnt to optimize their use of available resources and then, possible without knowing, used this culture to become highly-competitive in global markets. In the same manner, today developing countries, such as Mexico, tend to be more capable of conducting good supplier negotiations than counterparts in the United States, because their understanding of limited resources is much clearer.
Within the automotive industry there is some consensus that cars built in Germany normally have good craftsmanship. One of the ways to asses this parameter indirectly, is via the quality of door closing sound and feeling. While launching (beginning the production run) of a new car in the United States and in Germany, the director in question, was responsible at both plants for leading vehicle craftsmanship. While in the United States launching the vehicle, door closing quality was improved and taken to acceptable levels; later all the design changes were implemented in Germany for the launch in Europe and it was found that the door closing quality was unacceptable. Objective measurements proved that doors built in Germany and the United States both performed well, however in Germany customers and engineers complained. Further redesign to the door was needed before acceptable performance was achieved, however upon reflection interesting insights were seen. In general houses in Germany are made of stone and brick, and doors made out of solid wood. In the United States the norm is to use wood structures and drywall for the house and lightweight doors for the most part. These characteristics make doors in Germany close like vaults, and those in the United States with some shake and lack of solidity. The conclusion drawn from this was that engineers, and customers, were used to solid thuds from doors in Germany; and this would drive engineers to design and deliver doors with what is named better craftsmanship. The change in door closing quality, has therefore, nothing to do with the organizations ability to accomplish the work or produce the vehicle; but is rather greatly influenced by the expectations of each individual within the organization.
5.4.3 Core Competencies
People, are without doubt, the essence of what a product development organization is. It is interesting to see that within Toyota this is made explicit by understanding that "making products" emanates from "making people". This is made actionable by actively developing the best people in their organization and by ensuring that all employees have an excellent understanding of what the Toyota way is. This is epitomized by the role of the Chief Engineers (shusa) at Toyota, who are considered to be the true car guys of the company (Dehoff & Loehr, Innovation Agility, 2007).
Development of competencies that are owned by the team as a whole is one of the manifestations of a good organizational culture and a building block for further progress. The selection of the core team competencies is a prickly subject, with some authors (Collins, 2001) even contending that core competency selection is an error. We will not attempt to prove this point one way or another, but when attempting to focus the limited resources of the organization to develop team competencies a selection must be made. Research in literature on strategy and organizational growth and change, along with extensive reviews with over ten upper management people for North American Car

produced four core competencies that a product development organization can strive to develop.
These are the following:
* Excellence in Communication * Flexibility of Organization * Nimble and Robust Decision Process * Perfect Execution Mind Set
We propose that an organization can take actions to develop each of these competencies and use
them as the common denominator in all their product development activities.
5.4.3.1 Excellence in Conmm cation
Communication in product development enables us to conduct product development activities by
providing the means to transform and transmit information from one end of the product
development process to the other. Communication as is so important to product development that
the whole of Chapter 4 is dedicated to the many nuances of communication within the product
development organization. Incentivizing the organization to communicate and acquire
communication as a core competence can by done by promoting a culture of respect amongst team
members and by not tolerating behavior that disrespects any of the organizations members.
Communication is a requirement for efficient product development, improving execution of product
development both toward the inside and outside of the PDO. Work on technical issues during the
development of a next generation of small SUVs for North American Car presented an example that
highlights the importance of good communication. Engine mounts for the SUV were carefully
designed and tuned during the right product development phases, and the design was finished in a
timely manner months before starting production. However, upon beginning the first trial runs for it
was noticed that the engine mounts being delivered to the assembly line were not meeting the
targets for vehicle noise and vibration levels.
S..ampe ID X-Axis Static A% Y-Axis Static A% a from target Ks fromtarget Ks
Z-Axis Static 6% from target Ks
215 .29 I~ll:BK
Figure 5-4 Engine mounts and issue description for future model SUV
100

Detailed investigation into the issue revealed that a series of communication issues were at the root of the problem. To begin with, the supplier's engineer had never acknowledged the change in rubber durometer that had been directed by engineering and had thus never ordered the engine mount plant to use the new rubber formula. Additionally, within the OEM development team for the SUV there was disagreement in regards to what engine mount was desired and why. Even when all the necessary technical skills and knowledge were available, solving the problem came to a halt because of generalized poor communication. The problem was finally solved by conducting a couple of well organized design reviews and ensuring that all the proper information was available to all team members.
.1 {2 Tlcxilv n The ability of a firm to adapt to its changing environment is a characteristic that is of essence in light of uncertain market conditions and work responsibilities. There is a need for organizational flexibility that empowers management and the whole organization to nimbly change direction to best suit the needs of customers. This flexibility is one aspect that is easily lost within organizations as they grow from being small and dense, into larger more disperse ones. This is the reason why transforming, or leading, the organization to stay flexible to change is not only a goal, but must be seen as a competence in our current world.
Within specific product development projects one of the problems that show up time and time again is the need to provide the team with freedom to act but constraints to make it manageable. This observation has been made in the past and has been adequately framed as balancing firmness and flexibility: 'A recurring, problematic challenge practitioners faced was what we call "balancing firmness and flexibility" in project execution.'(Tatikonda & Rosenthal, 2000). Tatikonda follows on to mention that it is necessary to establish the bounds (firmness) in the process, but allowing for flexibility in the work (execution). However one question that is not answered here is at what level should one control the process before it becomes in effect a controlling of the work.
One of the ways to ensure that product development remains under control is by specifying the need for both firmness and flexibility. One way of achieving this is by providing firmness and stability to the organization through formal program management that allows for program control and a structure for its development (Tatikonda & Rosenthal, 2000). At the same time flexibility can be introduced in the allocation of resources and autonomy in the management of individual tasks. In this manner it is possible to strike a balance where sufficient checks are kept in place to avoid ambiguity and provide direction, but flexibility is provided to get the job done.
The long term goal of the organization should be to achieve structured flexibility, such that managing the organization is straight forward but nimbleness is maintained to the lowest levels (Tatikonda & Rosenthal, 2000).
Flexibility in product development allows a firm to tackle a diversity of engineering problems and drives engineers to engage in problem solving. The ability to do this can help reduce the cost of
101

engineering and stabilize work load. This happens because the flexible organization will move seamlessly from one problem to another and use the available resources in creative ways to solve problems. In many ways, consulting firms must do this continuously to adapt to changing customer needs and avoid becoming overburdened with people. An organization with a high level of flexibility to attack problems can be called a 'liquid organization' (Perez, 2007) because of its ability to change form as needed and use the available resources to fill in and solve the problem.
Growth of the organization in an organic manner is a desirable way to attack problems where there is a high degree of uncertainty in the task to be completed (Tatikonda & Rosenthal, 2000). Such is the case of most product development projects. One of the reasons why organic organizational approaches are adequate to high risk or uncertain environments is because they allow for high degrees of flexibility that are adequate for dealing with unexpected changes. However even under organizations that choose to approach problems in a mechanistic manner, allowing for flexibility in the execution has been demonstrated to prove benefic (Tatikonda & Rosenthal, 2000).
Ability to work as a liquid organization with high levels of flexibility is a competence that must be developed, and that quickly becomes part of an organizations culture.
,4,3.3 Nimtble( tk~n Press
Engineering is the exercise of making the right design decisions towards better meeting the needs of our clients. Decisions are at the heart of developing a product, without them we only have a disparate mass of ideas that can not attempt to solve complex problems or become successful in the market. Effective decision making is a competence that the whole team must develop, including both management and engineers.
The organizational structure is an important tool to improve the decision process, as in most cases people will follow chains of command to get problems solved. Good organizational design, allows for the decisions to be made at the lowest possible level of the hierarchy, but also encourages quick escalation of issues when they merit such treatment.
In small organizations the decision process is not of concern and the impact of how the organization is setup to robustness of decisions is minimal. However large organizations are greatly influenced by their structure in how efficient they can be in making decisions. Given that the design process is one of making decision, improving this one element can provide significant improvement in many areas of product development.
Process and organization are fruitless without our execution and interpretation. Each and every participant must direct their effort to executing with the utmost perfection. The success of projects, processes and any other endeavor depends on the what (i.e. a good process or new product) as much as it does on the how (i.e. the effort and mindset). This competency seems difficult to quantify, or even to fully grasp; but looking at successful companies makes it certain that it is
102

embedded in their every move. In addition to this, formal studies in regard to the implementation and execution of processes have concluded that quality of execution is directly correlated with project performance.
'Project execution methods are positively associated with project execution success.'(Tatikonda & Rosenthal, 2000)
The execution of a project must be an individual quest for perfection that has team goals. Each and every one of the participants must become hungry for delivering their own contribution to the project as best they can. This must be the result not of peer pressure, although it does help, but rather of their personal motivations to deliver the best results each and every time. Although this vision might seem utopic, it is only on the aspirations and dreams of each of the individuals involved that great change may take place. Only by capturing and channeling the unique desires of all participants can an organization grow to be exceptional.
This idea is further confirmed with findings such as that of the PMI (Program Management Institute) that cites 'project execution as the single most important factor in the success or failure of new products.' (PMI, 1998).
5.5 Organizational Learning
In order to achieve the goal of continuous improvement Toyota has developed a core capability that allows them to effectively capture and share the knowledge they gain at every step (Dehoff & Loehr, Innovation Agility, 2007). Because of this Toyota avoids making the same mistake twice and is thus able to continually improve its product development activities. Organizational learning is the ultimate goal of the lean product development team that understands that leadership in engineering is a matter of dynamic renovation and evolution.
One of the ways to best improve organizational learning and achieve dissemination of knowledge to the whole organization is the development of true product leaders; in our case the true 'car guys'. Within Toyota these leaders are known as shusa and within NAC as Chief Engineers; upon analysis the difference of the roles played by both sides is significant. The difference in roles played in each organization also changes the effectiveness of each in aiding organizational learning. A key component of the 'shusa' and the Toyota system that supports this role is the ability of the organization to learn and the mechanisms that have been developed to teach its members. Through years of careful training Toyota develops leaders that are excellent in their technical skills, but are also able to transmit knowledge and serve as hubs for learning.
The process of learning within the organization is in many occasions difficult to improve because information tends to be 'sticky'(Szulanski, 1996). Differences in the knowledge that is common between two parties - receiver and sender -- can severely limit the amount of information that can be transferred, and the lessons other individuals can learn. Because of this, even if there is excellent
103

technical knowledge of a certain system in one part of the company it may be very difficult to transmit this knowledge to other locations.
Finding better ways of doing a job is always desirable as long as the improvements become organizational best practices. We find that many times within corporations there are many people that have found better ways to perform their work. However, finding a better way is only a first step, the second and many times missing element is the discipline to transform the innovative idea into a proven process that is an effective best practice. The best practice must be able to improve how the job is done, and also demonstrate that it is capable of addressing the failure modes that were controlled by the 'less efficient' process (Browning, Fricke, & Negele, 2006). Discipline must be enforced to ensure that only changes that can be proven to be an enhancement become best practices. Otherwise, it becomes easy to be lured by apparent improvements that lack the capability and down to earth structure that will make them successful as best practices.
Organizational learning is essential to improving the product development system. Because of this management actions must be taken to ensure that knowledge is actively transferred amongst engineers and that all people in the organization are being successfully developed in the core capabilities needed to perform their future tasks. It is important to ensure that learning in the organization is not only of knowledge that can be presented on paper, but also of the kind that allows the generation of a constructive work culture.
In the design of the product development system, organizational learning must be one of the elements that are addressed by the organization. Knowledge and learning for the other systems - process, product - will find their needs addressed by the organization if properly established.
5.6 Key Takeaways - People and the Organization
In product development the people and the organizations they form are key to delivering high quality new products efficiently. This known fact makes changes to organizational structure and in general to the human capital of a company one of the prime aspects of organizational change. We find nine key takeaways, some of which are more specific to product development organizations than others.
1. Product development project leaders, should be the lead system designers. Analyses of best in class product development organizations all highlight the role of the project leader as critical to the success of product development projects. The key aspect shared by the project leader in all these successful organizations is the definition of the project leader as the lead system designer; a role that is intimately technical by definition. On of the best examples of how to execute this idea is provided by Toyota where the shusa (project leader) concentrates in one person the greatest level of technical expertise within any given program, balanced with a sound understanding of the market and business needs (Dehoff & Loehr, Innovation Agility, 2007).
104

2. The individual is the key element of the organization and must be treated as such. Development of people and culture is an ongoing process with many nuances. These include the fact that a balance between the individual and the group must be achieved. This balance must bring up in the individual those qualities that are most beneficial to the team. This becomes especially important for organizations going through an organizational change process; which depends on the cooperation and willingness of all employees (Sterman, Repenning, & Kofman, 1997) for success. Product development has been described as an information transformation process, marked by a continuum of decisions that lead to a finished design. During all this process the decision makers are mostly the individuals. Therefore the capability of each individual to take the right decisions has a profound impact on the overall performance of a product development team, increasing the importance of selecting and developing individuals within an organization. Three main strategies are identifies to help ensure the development of a stable and efficient workforce that optimizes the use of each individual and the collective team:
i. Create team goals and individual incentives ii. Drive accountability at the group and individual level
iii. Retain talent 1. Provide challenging work 2. Compensation 3. Growth opportunities 4. Stable and rewarding work environment
3. Good product development organizations work as single aligned and well synchronized unit. The alignment of all elements in a product development organization is key to delivering results. In this realm three aspects that are important and specific to product development have been identified: a. Make suppliers integral to the product development organization, using the system
boundary's to helps manage these relationships b. Clearly define roles and responsibilities in an integrated manner as enablers to
effective global product development c. Decide if the organizational structure of the organization will be project of function
biased, even when using a matrix structure
4. A successful organizational requires definition of the structure, its competence and its culture.
Improvement must take place in different parts of the organization at the same time for the effect of improvement to be felt (Sterman, Repenning, & Kofman, 1997). Therefore holistic approaches to change must be taken; for the product development system this means improving, or at least considering, the impact of change to the architecture of the organization. In general the architecture of an organization can be said to be made of the tangible organizational structure, the inherent capabilities and the intangible culture that dictates how the organization works.
105

5. Knowledge and the process to accumulate knowledge key assets of an organization.
The ability of an organization to learn form its mistakes and successes in a systemic manner is key to the improvement and growth of an organization. For product development the knowledge of the organization is one of the most valuable assets it possesses. Methods and practices to ensure that product development organizations accumulate and more importantly 'use' knowledge are key to increasing the capability of a product development organizations.
6. An organizations leader can determine the success of an organization and / or project. Given this generally accepted point of view, seven aspects of a good leader are then identified - good leaders must:
a. Motivate the organization b. Facilitate problem solving by removing barriers c. Ask 'why?' intelligently d. Focus organizational efforts toward clear and stable objectives e. Design, develop and maintain the organization to maximize throughput f. Promote trust and respect g. Promote learning
7. Organizational culture can be designed and developed to improve performance.
The culture of an organization is not a static or unmovable, it can be designed and made to fit the specific purpose of an organization. In general the culture is made of the implicit assumptions all members of an organization share. These assumptions then create stereotypes that become a trademark of an organization and can have a profound effect on the ability of an organization to live up to new challenges. Definition of desirable cultural traits for an organization is key to ensuring we create a culture that is the most beneficial to the company's business environment.
8. Generating accountability for team projects at the individual level is at the core of an organizations ability to deliver results.
Accountability has been found to be one of the key elements in organizations that have delivered successfully during crisis and on critical challenges. It has also found to be one of the key enablers of high performing teams, such as those found in the racing car development teams of NASACR and the WRC. In product development organizations generating accountability is a function of organizational structure, process and culture.
9. The best organizational structure for a given product development organization is the one that best helps us flow our customer needs and requirements into finished products.
As a rule of thumb, the organizational structure of an product development organization should strive to improve the flow of information from customer needs to a finished design. The factors that affect this structure include the country specific cultural traits, product technological change rates, product complexity and organizational size.
106

How we design the organizational structure is a key structural decision in architecting and designing a good organization. The ability of an organizations leadership to understand the role the people and their organizational structure will play is therefore essential to success in highly competitive industries such as the automotive.
107

6 Product and Process
The intimate link between the process to create a new product and the product itself is undeniable;
improving the synergy between both is key to increasing the value companies create. In designing a
product development system our ability to balance both is critical. Conceiving and designing vehicles
that better meet the needs of customers are the main objectives of automotive product development organizations. Both the product and the process to develop new products are
considered proprietary information; the product is proprietary for the immediate competitive
advantage it provides the company, and the process because it summarizes all the knowledge that a
company has regarding the steps, interactions and resources it requires to develop a new product.
Process and product are intimately linked. Within Toyota it has been said that their products are the
result of careful and disciplined process execution (Sobek, 1997). However we can also argue that their processes are a consequence of having hands on experience and excellent learning mechanisms - products -- leading to develop best in class processes (Dehoff & Loehr, Innovation Agility, 2007). Additionally, concurrent product development processes, the current best practice in the automotive business, requires superior alignment of product and process for optimization (Loch & Terwiesch, 1998) increasing our need to find a relationship between both. As a result, we can easily to get in a chicken and egg dilemma, yet the research presented throughout the chapter
points toward concluding that in most cases focusing on delivering the product in a disciplined and
systematic way is both easier and more intuitive than beginning by looking at the process.
Product development can be seen as a deliberate business process that requires hundreds of
decisions, and ends in a product (Krishnan & Ulrich, 2001). Matching both ends to work as one is important, and within this chapter we will look at key characteristics of both, product and process.
Product development organizations normally align their structure to match their current PD process
and this can in many occasions result a misalignment within the organization (Sosa, Eppinger, & Rowles, 2007).
6.1 The Product
Many of the western product development organizations have in recent years focused solely on
process to improve their product development capabilities. The intense focus on process is derived from observation of the Japanese approach to product development, considered to be the best in
the world; however this approach has sometimes missed vital aspects of Japanese product development system. The need for having a process is not disputed, but an organization that requires an army of process police is highly inefficient (Dehoff & Loehr, Innovation Agility, 2007). A next level of analysis of Japanese product development practices brings to light an intense focus on delivery of technical goals to meet customer needs. This subtle difference is key, as it directs the organization toward the customer and empowers the team add value.
108

From the three variables - cost, quality, time to market - that can be attributed to work of a PDS, development cost has been proven to be the least correlated to product performance in the market. Improvement in time to market and quality both have greater positive impacts on the products performance in the market place. Improving technical functionality and reliability, which we group under PD quality, are two of the features available for a product development team to add value. These features, in particular, have been correlated to increased sales and can therefore be considered critical product features for success (Takikonda & Montoya-Weiss, January 2001). This evidence seems to go against some of the normal tactics used in the industry today, which start the design process by reducing cost, instead of focusing on increasing the product's value proposition.
Developing a product requires iteration, experimentation and redesign, with information flowing back and forth between departments in order to solve problems that arise. Within product development simultaneous and conscious execution of different stages of this iterative process it is known as concurrent engineering (Eppinger, January 2001). Concurrent engineering is widely spread in the automotive industry and has helped some companies - Toyota, Mazda - select an optimum design quicker. Good implementation of concurrent engineering practices can help product development organizations improve the iterative engineering process and streamline information flow.
Examples of failures to focus adequately on the problem or product and instead look only at the process happen every day. For example, in the development of a new small car, I was involved in delivering the NVH (noise vibration and harshness) attribute. When the vehicle had been conceived, customer research had pinpointed a quite interior as a key attribute. Objective targets that had previously proven to correlate well with the perceived quietness were selected and the program got to work developing a car that met them. However a year and a half into the development of the vehicle a milestone event brought to light an interesting aspect of the vehicles interior quietness. Objective tests showed that the vehicle was achieving the set targets, yet drivers and passengers alike would find that the vehicle was no as quite as they expected. Some of the programs leadership dismissed the problem and as being unimportant because the metrics in the process were 'green'. It took more than nine months for the whole team to look at the product in the right light and pursue changes to deliver on the customer want creating excessive rework. In this example the process dictates that the target be established at the beginning of the program and maintained throughout the development, this is a best practice and following it helps minimize churn in the program; however when focus on the product is lost to meeting the process we must look to rebalance our approach.
For the development of the product development system a focus on product value can help guide tough decisions and maintain the system directed toward delivering customer value. In the following sub-sections we provide a brief review of the product as seen in product development through the four major stages of development - define, design, validate, launch -to understand the importance of the product in helping guide the product development system.
109

6.1.1 Define
The first stage in the development of a product is the definition, and it is at this stage that most of the end product's potential is determined. The potential of the product gravitates primarily around the value equation it defines. In engineering terms finding the products value equation has been called systems architecting (Maier & Rechtin, 2002) and helps link elements of form and function to customer value through a concept (Crawley, 2006). The definition stage of a product development project must help provide clarity regarding the needs the product will solve and a specify conceptually 'how' this will be achieved.
Identifying customer needs is key to the definition stage. Customers are seldom aware of what their needs are and must therefore be helped provide the answers we require. One of the first steps a product development team can take to achieve understanding of the market and product is to immerse itself in the problem (Deboer, 2007). The 'immersion' technique consists in becoming a customer and living the needs of the customer. This technique has been proven in many scenarios, products and companies with great results, however, many teams forget that the key to the success of the immersion technique is to ensure meaningful data is gathered for future analysis. Gathering meaningful data requires teams to structure their immersion exercises and develop high quality post-immersion methods to objectively capture the knowledge that was learned.
The definition stage provides the team with the most opportunity for success in the market of all stages because of the immense freedom it presents. At the same time, it is also difficult to execute well as most of the work is done at the conceptual level. During definition the cost and effort to integrate the full value chain and full life cycle of a product is considerably lower than in later stages. Therefore, all decisions made during the define stage have a significant effect on the potential of the product to deliver value and determine the ease with which we can achieve success in the next stages - design, validate, launch.
Identifying product attributes on which customers will not be willing to compromise on is a skill that product development teams must acquire to be successful. A single product failure in the wrong area can determine the overall fate of a product and it's ability to meet customer expectations. The definition of the product in terms of subjective product attributes is normally the responsibility of marketing, while the translation into objective metrics and targets is the work of engineering. In product development best practices both groups - engineering and marketing - work together to ensure that there is an accurate capture of the customer needs. In the process of identifying customer needs, finding the attributes where there will be no compromise on behalf of customers has proven to key to improving the performance of product development teams.
Project feasibility is established during the define stage. The product value equation must provide confidence that the product can be designed and developed to meet the customer needs and the manufactured economically in a way that makes it competitive in the market.
In essence, the define phase prepares the team to conduct the development of a product by aligning and clarifying the product concept. Only during the definition stage can alignment of priorities
110

amongst different functional groups - manufacturing, engineering, marketing - be achieved, thus, helping insure that overall product success is achieved. The product plays the central role in this
alignment process as it spans beyond the reaches of functional activities and ensures that everyone aligns toward improving how the company satisfies customer needs and creates value.
6.1.2 Design and Validation
Having defined a product, it's design and the subsequent validation to ensure that we meet the customer needs are both central to product development and the areas in which traditionally the most engineering resources are spent.
Design and validation, as well as the rest of the product development process are in general prone to high levels of risk. Whenever there is risk involved it becomes a best practice to devote some portion of the resources available to conceiving alternate solutions to a problem. Within Toyota (Dehoff & Loehr, Innovation Agility, 2007, pp. 3, 4) it is customary to always have more than one concept to solving the engineering problem at hand. Of the solutions that must be presented, it is
always required that at least one of them be a proven solution that presents a default backup plan. Working this way allows the team greater freedom to develop other more risk prone solutions. Without this approach engineering programs incur in unnecessary risk.
Risk management at the individual component design level quickly takes a toll over the whole organization. Risk aversion of the whole organization is dependent on the ability of each area to
manage its risk internally. When risk can be contained within a subsystem or functional area the
expensive and lengthy process of cascading changes is eliminated. Removing these negative connotations of risk allows management and their respective organizations to tread further and with greater confidence.
The efficiency of the product development organization is in determined in great part by the ability the product development system has to manage development risk in the most efficient manner. For example, some automotive components and sub-systems are best left to be engineered and manufactured by suppliers than by the OEM. In those cases where the OEM has decided to outsource the engineering the detail of what and how it is done, is mainly an issue of risk management. Separating the risk that the OEM can comfortably take, from that of the supplier, can lead to significant reductions in the cost of engineering and manufacturing. Most of the activities that relate directly to risk management take place during the design and validate stages, and how we make the choices greatly affects overall engineering costs.
Validation and design activities are highly iterative in nature and go through cycles of improvement until the final design is achieved. Planning these iterations is complicated and is normally guided by experience in the field or probabilistic estimations. Developing good models to acquire an understanding of the development process is necessary to allow for planning, yet care must be taken to avoid over planning; room must be left for the unplanned iterations (Browning, Fricke, & Negele, 2006). Therefore planning must be done with the understanding that we will not be able to
111

define each and every part of what will be needed to develop a complex system, but we will provide
an initial approximation with key dates and events and develop the plan as visibility of each event
increases. Good planning is key to good design and validate phases.
An essential aspect that is shared by validation and design is the focus on removing error states from the product (Aguirre Esponda, 2008). Most of the times the design and validation stages focus on delivering additional content or incremental features, yet it is through the elimination of error
states that the greatest gains can be made. Fatal error states are normally less in normal, than the desirable attributes or product characteristics; focusing on the upside leads to never ending quests for the most complete list of customer wants. Focusing on the unacceptable failures on the other hand clarifies the problem and portrays the requirements as design problems.
Many large companies have adopted some form of system engineering to help them in developing new products, yet subtleties in how the system approach is used can mark the difference between success and failure. Design and validation can be done in many ways, but some companies that believe they are following a system engineering approach have decomposed sequentially then designed and validated in disaggregate form and finally reintegrated, with little consideration of the true system level problems. This approach, has demonstrated to deliver poor results. The reason for
this lays in the assumption these organizations have made, that one can efficiently decompose the
system at each level and then, without having designed with the full system in mind, integrate a final product. A good example of why this does not work is that of full service suppliers that are
employed by OEMs to deliver full sub-system solutions. In general these interactions are ruled by extensive and very complete sourcing agreements and engineering statements of work that are probably the closest to a full interface definition one can get. Suppliers that focus themselves on delivering the content of the agreement without coming back to work at the system level find themselves quickly with situations where they have completely missed the overall development effort direction. Within a single corporation development of detailed interaction agreements can be even more difficult, and it is therefore important that companies ensure that their approach to
system engineering strives for integration of all aspects of the product and a holistic view of problems.
Customers have both implicit and explicit needs; delivery on both sides must be accomplished during these phases for success in the market. Engineers quickly forget about the non-functional and non-explicit needs, yet without them the product does not deliver the full customer expectations and will thus by subject to pricing penalties that reduce the perception of added value that the customer has of the product. During the design and validation phases an effort must be made to ensure that the team delivers on both the implicit and explicit needs.
Validation in general can choose to balance the quality, cost and timing of its endeavor in a manner similar to the overall product (Krishnan & Ulrich, 2001). Balancing of the prototype cost and the redesign cost are amongst the variables that can help optimize prototype strategies.
112

Validation of new products should be directed both at making sure that customer needs are met and the design objectives are complied with. Validation should in addition seek to inure that the product as designed elicits customer desire and a sales opportunity for the product. To do this properly the validation must include engineering, manufacturing, sales, operation, service and end of life requirements. Validation constitutes a large part of the cost of product development and consumes significant amounts time. Improvement in the speed of validation and product development does not necessarily lead to shorter time to market but will enable development of enhanced products (Cohen, Eliashber, & Ho, 1996).
6.1.3 Launch and Implementation
Launch and implementation of a product design are both necessary steps to deliver the product to the customer. The design and validation must be made with the goal of flawless implementation, yet conducting this stage with utmost care is the difference between having a good design and a good product. For the most part good designs that have considered the implementation side of the product in advance will succeed in launching and implementing the design, yet specific actions toward this goal must always be taken.
The key aspect of launching a product is ensuring that the product as designed starts to be manufactured in volume. Accomplishing this goal requires understanding the critical variables in the manufacturing process and controlling them to achieve the desired output. The identification of these variables should be complete before entering the launch phase, and it is therefore a task of working as a team - manufacturing and engineering - to achieve control over the manufacturing process.
6.1.4 Additional Product System Observations
Conceptualizing products from a modular perspective allow teams to quickly create variants, and in doing so increase the profitability of their product lines. The architecture of the product is the key to being able to do this (Evans & Webster, 2007). Modularity has been one of the recent tendencies in complex product development, yet carful consideration to the cleavage point between systems must be made. For all projects detailed knowledge of the architecture should be done by at least one member of the team. In particular when dealing with modular products the architecture will limit or increase our overall flexibility and give the product development organization opportunities to increase the added value.
Knowing the customer first hand is important as an overall strategy and as a learning tool for the development team. Being able to convey this knowledge to the most people on the team empowers them act and take the right decisions. The decisions that take the need and get to a manufacturable design are taken one at a time by a variety of individuals; therefore the more we empower the team the easier it will be to deliver a successful product.
113

An aspect of consumer products that is not sufficiently mentioned during development is the
positioning of the product in the market and how the product is marketed. Brand definition is in
most cases the realm of marketing. However as we have previously stated, best practice within
systems engineering dictates that marketing should always be considered. My work in the
automotive business has shown that for attribute development in different brands development of
a sense for the brands characteristics is necessary to ensure that the finished product is consistent
with the brand message. The product development process is entrusted with the task of taking the voice of the customer and the concept to deliver the product into reality. Having consistency and
developing a brand has been demonstrated to be a strategic capability of the development offices of
some of the most successful companies in recent times. Apple has epitomized this competence and
created a cult surrounding its products. Looks, functionality, service and experience are all part of
this cult. In looking for a way to marry all these items together, consistency seems to be one of core differentiators.
6.2 Process
'A process is "an organized group of related activities that work together to create a result of value" [Hammer, 2001]' (Browning, Fricke, & Negele, 2006)
'The process is in many ways the nexus of the systems interactions: if the project were a sentence the process would be the action verb.' (Browning, Fricke, & Negele, 2006)
The process in the product development system provides the general path that must be followed to
deliver the product. The product focus that was presented in the previous section must be balanced
with the need to have standardized reporting means and some way to allow the organization as a
whole to improve their processes without reinventing the wheel each time. This objective seems contradictory with the previous idea of not focusing solely on the process, however as some firms have demonstrated this is not the case. Successful balancing of product and process is done by
some organizations by having the engineering team (responsible for the product development) work on developing the next generation of product development process. Doing this makes the process
align with the needs of the development activity; motivation to follow the process has shown to be stronger by using this approach in many cases. However, a way of achieving the larger company
objectives is also needed and therefore having a centralized lead for the process improvement efforts is desirable.
All PDPs (product development processes) are models of reality that can be either prescriptive or descriptive. Models that are descriptive capture how things are done in reality and attempt to present them in a way that allows others to follow the same general steps. Prescriptive models on the other hand, attempt to provide a model of how things should be; inspiration for these models comes from existing models in other industries, research and other resources (Browning, Fricke, & Negele, 2006). Both the prescriptive and the descriptive models are needed in the product
114

development process; and each serves a different function. In reflecting reality descriptive models
allow the team to look for opportunities to improve their execution.
'It is healthy for an organization to gradually evolve portions of a descriptive process model into a prescriptive one, rather that to pull a prescriptive model out of thin air.' (Browning, Fricke, & Negele, 2006)
'Having a prescribed way of doing something needs to be reconsidered in the context of PD as meaning having a hypothesized way of doing something.' (Browning, Fricke, & Negele, 2006)
The process for product development and its specific application to a project is useful as management and leadership tool. The process serves as a mental model of the leader empowering the team to contribute meaningfully toward the project in an orderly manner. To achieve this successfully the process must be specific to the product, considering the nuances that are key to its delivery. Focusing on the product makes the process meaningful for engineers and helps management focus on delivering value to the customer. One of the immediate benefits of this approach is that it allows project teams to follow the product development process with less need of process managers.
The activities that take place during the development of a product have many kinds of relationships amongst them. Realization of this becomes especially important when one is attempting to redesign a process that is made out of a series of individual activities or tasks (Malone, Crowston, & Pentland, 1999). Malone et al. show in their paper on Tools for Inventing Organizations that we can broadly classify all dependencies into 3 main groups: flow, share and fit. Flow dependencies take place when the output of one activity is required by another one to complete its task. Share dependencies occur when 2 or more activities must share the same resource (be it information, lab space, prototypes or others) in order to complete their activity. And last fit dependencies are when we require several activities to work in parallel to deliver their task. As we have mentioned before many of the activities undertaken by product development fall under this last category, either because of the nature of the task or because increased pressure to reduce cost and time for development have driven activities to become parallel. Whatever the case, be the relationships of any of the three kinds mentioned, understanding that there are different requirements for the organization when undertaking a different approach is important to ensure that we can properly redesign a process or even just manage one effectively.
Fit Flow Sharing
Key: O Resource rI Activity Figure 5 Three Basic Types of Dependencies Among Activities (Adapted from Zotkin 1995).
Figure 6-1Basic kinds of dependencies (Malone, Crowston, & Pentland, 1999)
115

The process oriented approach is normally well suited to studying organizations involved in business activities or in our case product development. This mainly because it allows us to identify the connections that exist between organizational barriers at the activity level and also because in doing so it highlights new ways of accomplishing old tasks. In this regard the understanding of dependencies within an organization becomes very important to enable a correct analysis of the situation at hand. Upon first approach it normally seems easier to begin by addressing the immediately obvious relationships amongst departments. However doing so can be a mistake as it has been seen that in reality the dependencies always occur between the activities (Malone, Crowston, & Pentland, 1999) and that it is from here that we must engage the redesign of a process that is robust and adequate for our needs.
One of the dangers of embarking on a process oriented redesign of an organization is that it is
possible to quickly over constrain the system and have people begin to use and interpret the process to rigidly (Malone, Crowston, & Pentland, 1999). Even though the intent may not be to prescribe, providing an excess of procedures or rules can drive the organization to regard the process as a prescription and no longer as a tool for accomplishing their job.
The definition of interface specifications (Eppinger, January 2001) is a critical task for any successful product development team effort. The specification allows the task to be successfully partitioned into smaller parts that can be subsequently reunited. The creation of these specifications is greatly improved if there is a good understanding of what the future needs of other activities are and what the tasks prior to it have accomplished. For this purpose the DSM provides a clear graphical insight into the overall process allowing the creation of interface specifications that are useful to all parties involved. These interface specifications are useful both when looking at the internal and external parts of the projects.
The process of product development must always choose a balance between the cost and quality of
the product to be created. In general processes that are highly coupled encourage the development of solutions that are highly innovative and are likely to produce products of improved quality. On the other hand decoupled processes have the tendency to speed up the development of a product by allowing increased parallel tasking, but are less probable to innovate or significantly increase the quality of the product (Eppinger, January 2001). This trade off must be managed and understood in order to allow companies to drive their product development in the right strategic direction. The following are two ways to modify the relationships amongst product elements.
'First, you can transfer knowledge between teams. In some cases a company can decouple a task form another simply by adding to each team someone with expertise in the other task.' (Eppinger, January 2001)
'Second, you can introduce a new task earlier in the process so as to simplify subsequent, time- intensive iterations performed by interdependent teams.' (Eppinger, January 2001)
116

An organization intent on trying to change its process by brining in an external source to revamp its operations is confronted, in general, with significant resistance from the working force. As
described by Repenning and Sterman the main issue for engineers is that new processes seem to
initially drive increased complexity and require more time to accomplish that the old ways do.
Because of this resources spent on the implementation of new processes can be wasted if there is
not a significant effort to make the organization understand the need for an improved process and have them participate in its development and implementation.
On the management side, we must also consider that all changes done to the process will require time to implement and even more to show their true potential. Nevertheless many times new processes are dropped by management before there is an opportunity for the organization to embrace them. This is driven by a lack of understanding of the time delay that exists between implementation and changes in the output of the system. Being able to provide stability through the implementation of changes is thus one of the core responsibilities of those in management while brining improved processes to the organization. It is thus that we see that successful organizations have followed a stable and continual path of process improvement with incremental changes on an almost daily basis and few but very well focused systemic changes that are aimed at transforming their status quo.
The delay that exists between the true cause of a problem and the appearance of symptoms is one of the main difficulties in being able to correctly diagnose what must be changed in a product development process to enable significant change (Repenning & Sterman, 2001). Difficulty in tracking the source of the problem back to a development activity makes systematic improvement of product development impossible without a well setup learning system. A tool that can aid in solving this problem is the DSM which by answering the question "What information do I need from other tasks before I can complete this one?" (Eppinger, January 2001) can create some guidance as where the root cause of the problem can be found.
Even though the process for each product is slightly different, the base structure for the process and the subsequent detailed interactions can be largely reused (Tatikonda & Rosenthal, 2000). Sets of basic activities are needed to develop any product from a selected industry. For example all automotive products go through certain vehicle dynamics test to prove their stability and cornering; execution of these tasks can be standard with little impact to the specific program. However, there is also a different view on the problem and that is that by and large every development program is unique and can therefore be compared to doing something new every time (Browning, Fricke, & Negele, 2006). Best in class organizations solve this problem regarding the process, by identifying the largest block of activities that are not project specific and creating standardization at the small end and customization of the overall process. These blocks can be likened to Lego blocks of activities and deliverables that can then be easily pieced together to make the process structure (Browning, Fricke, & Negele, 2006).
117

6.2.1 Product as the Result of Information Transformation
There are two main activities: transforming the information and taking the information from one
element to the next. It is important to distinguish between these elements because there are error-
states associated with the information transfer problem that are unique to each group. On the other
hand transformation elements generate noise in the system and can even distort it in such a way
that all sense is lost in the signal.
'In product development, activities require information ... most product development activities use a set of inputs rather than a single one.' (Browning, Fricke, & Negele, 2006)
One problem with looking at product development as information transformation is that within
product development it is not clear which elements we want to classify as the transformation
elements and which ones as the transmission elements. This problem arises from the fact that as the
system or process grows in complexity we can introduce feedback, redundancy and multiplicity of inputs and outputs that severely affect our capacity of distinguishing one element from another.
Leaving this problem aside we can see that for the product development process we can find a
source, our customer needs, and an output, the finished product. These elements have the inherent
difficulty that the source - customer input - is normally weak and the output - the finished product
- is a very strong signal. If we analyze the source we find that the voice of the customer can
normally be considered a weak input that requires some degree of amplification and filtering to
enable further product development work with it. On the other side of the system, we have a
finished product that has tangible elements that in theory embodies the needs of the customer. The
output signal that the product sends is strong and we have therefore changed a weak but clear
customer input and transformed it into a strong signal. This transformation many times happens without a cognizant knowledge of the engineering team that they are delivering a product to meet
the needs as established by the customer; this is important because in general within the
development system the voice of the customer quickly loses strength and is replaced by engineering
assumptions that can be disconnected from the actual needs.
The result of the situation described above is that we can easily loose track of what our original
signal was (customer needs) and end up delivering unsuccessful products. One counter measure to this problem is to build the customer need into the product development process, ensuring integrity
of customer needs at each of the process milestones. This practice can lead to an increasing number
of mandated forms and documents that must be completed to communicate and may not always
achieve the desired result. It has therefore been observed that combining a process the ensures the
continuity of the voice of the customer and having direct exposure of key engineering people to the customer needs can leads to the best results.
In many regards product development processes have been successful in solving part of the
fundamental issue of information loss; however it is clear that some companies are much more
effective at doing so than others, and analysis of the process reveals that many of the same
118

elements are present between companies, yet don't result in equally competitive companies in
product development. It can thus be speculated at this point that some of the differences in the
effectiveness of product development activity lay in the execution of individual tasks that conform
the system or in the information we have selected as crucial to be transmitted.
The transformation of the signal is the design and engineering activity. For these design rules and
historic evidence is available to enhance our performance and ability to take a need and successfully
convert it into a design. Given that there is some generic evidence that the product development
process is not on its own sufficient to drive effective product development, it is important to
address the other critical element in the product development activity, the human one. To engineer
is human and to attempt to transform this activity to a mass production exercise driven by endless
kanbans is a mistake. Rather individual aspirations and inputs to the product development system
are desirable. The best product development systems in the world, such as Toyota, are driven by a
carful combination of process, product and people.
6.2.2 Standardization and flexibility
In some regards a process can be designed to allow for either great flexibility in its execution or for
rigidity and standardization. However it is also possible to selectively create flexibility and rigidity as
required at different phases of the product development process. Selection of areas of flexibility
requires deep understanding of both the organization and product.
Standardization must take place not necessarily at the general process level but at the more specific
task execution levels. As an example, all development programs will require unique validation plans
but all will conduct tests and require reporting mechanisms. Identification of the unit component of
the process is important to standardizing with flexibility.
For activities where regulation and go/no go choices must be made, rigidity can have significant advantages. It provides rigorous revision of the minimum set of requirements needed to continue.
Rigidity also contributes to multi-national teams working effectively over a variety of projects without the need to regroup at the beginning of each.
6.2.3 Process Engineering
The process followed by product development organizations to deliver their work is in a state of
constant flux. It changes both on the basis of new understanding of the tasks at hand and with the architectural evolution of the product we are developing. As such the process needs to be engineered and designed to keep up with the changing environment.
Work to generate the next generation of processes can come from different sources. Most commonly there are two options. The first is that the team working on the product itself generates while working an improved process. Second that an external team of experts generate the process and then deploy to existing product teams. Both options have pros and cons.
119

Being able to have the team both complete its work and continually improve and develop the process used to do the work, is not a trivial matter. It requires that organizations first acknowledge that this will be their operating manner, and then take actions to empower the team. Here these actions can take the form of information technology tools that allow collaboration across wide spread teams and knowledge building processes (Dehoff & Loehr, Innovation Agility, 2007). The information technologies are implemented to provide the team with an efficient manner to interact in real time with all other team members and to provide a way to capture what the current state of the art is for any activity at any given time. The use of these tools, which in many cases is low, then depends on having a knowledge building process that provides guidance on how to build new ideas into the existing process.
"Toyota seems to have a mature perspective on process models, treating them as the company's repository of state-of-the-art knowledge about how to do work, but constantly subjecting them to the scientific method" (Browning, Fricke, & Negele, 2006). Our intent to deliver a way to achieve the next state of the art requires both to have an intimate knowledge of where we stand today and an agreement on how to present the path that must be followed in order to achieve the next level of product development efficiency. In summary development of learning capabilities are core to evolving the organization.
Another aspect that Toyota has evolved to aid in learning about their process is the explicit use of hypothesis to begin any modification to their existing process (Browning, Fricke, & Negele, 2006). Even though it is understood that it may well be impossible to define what the best way of completing a task is, proposing a hypothesis helps generate a clear path toward learning. The exercise of setting up the hypothesis helps us deal with two issues. First, that in order to construct a hypothesis we must achieve the greatest level of understanding that we can at that time so that all critical parameters and relationships are touched upon in our hypothesis. Second it necessarily makes us define what the current state of affairs is because in great part a hypothesis will refer to differences between what is found today and what we expect to have tomorrow.
"The different phases of product development are best addressed by separate (but integratable) process models, and care should be taken to distinguish the similar activities in each phase accordingly." (Browning, Fricke, & Negele, 2006) Many times it seems desirable to attack the whole problem of the product development activity in one piece in order to achieve the maximum amount of global optimization possible. However previous attempts to do so have shown that it is desirable to address the different phases separately, but with a clear understanding of the relationships and how we intend to join all the separate pieces back together in the end. This implies that we must both be able to separate the whole into smaller parts but also have a vision of what a final aggregated product would look like. In this manner it is possible to attack a problem as complex as PD and still achieve a high level of depth in all areas allowing for optimization of the whole system.
120

6.3 Alignment of Product and Process
For both model and research results, if projects are to succeed, then a product development process must bridge the thought-worlds of engineering and marketing, and promote freely-flowing communication. (Griffin & Hauser, 1992)
Product and process must align, yet selecting how to balance the influence of each within the
product development system can be tricky. Product is at the center of all the activities in product
development and as described previously the process provides the bridges for communication and
interaction with other activities and within engineering. The process is in many ways a means to an
end, and great attention must be given to it because of its influence on the outcome of the product
development system. However it is easy to become overwhelmed and allow process to dominate
over our product.
Within Toyota at first glance the process has taken precedence over product. However under
careful inspection, this approach in itself is but an interpretation of what Toyota has identified as
their customers voice. Toyota focuses on the customer, then on their product and from here defines
a manufacturing based product development system that ensures that all products by Toyota will be
built to the highest quality standards and zero fatal flaws. It may seem that talking about Toyota in
this manner is overdoing it, but today in the roughest parts of the world, people will rather wait years to get a Toyota Land Cruiser than any other SUV.
It has been proven that balance is critical, but choosing a starting point depends on the product,
technologies and organization. Generically we can say that striving for a product oriented process is
a desirable direction for the automotive industry given that the rate of technological change is constant and relatively slow and that the industry is well established. From here it is the purpose of
the process to ensure that the maximum added value is captured within the product and designed to reach the customer.
Process provides a link back to the product by serving as an active repository of the knowledge the
organization poses in product development. Lessons from developing products that are systemic in nature can be captured in the process as best practices and later incorporated to all upcoming products. Using the process as the mechanism to transmit best practices is a way to assure that mistakes never occur again.
Currently product development in the automotive industry has tended to go toward developing modular vehicle architectures. Over twenty years ago the PC took a similar route and standardized interfaces creating modularity, from these changes enormous changes in how the industry behaved came along. For companies and industries that want to migrate to modularity, such as the automotive industry, consideration of the organizational and product development system changes required to make the transition are a major concern. However, some of the concerns are positive as modularity has been seen to act as an enabler of alignment between process and product (Sosa,
121

Eppinger, & Rowles, 2007). Attention to what subsystems are selected becomes critical to the success of modularization strategies.
'Some process models actually enable creativity and innovation to flourish: an appropriate amount of structure is needed to focus innovation on the most valuable problems instead of letting it "reinvent the wheel".'(Browning, Fricke, & Negele, 2006)
Process can also help the product system by providing structure areas for development that create incentives for improvement and innovation. The process provides the PDS with the base from which to reach out for improvement in other areas, product innovation in particular. The process is executed by the organization and stability also provides fertile ground for people to develop integraly. It is important to develop both the organization and process in parallel. Looking for an optimum compromise between them requires a case by case analysis. Some of the elements that most tangibly influence our choice are available tools, complexity of the task, novelty of involved technologies and pre-existing organizational structures.
Steven Eppinger (January 2001) presents the DSM as a powerful tool to improve and diagnose the interface between the process, product and organization. In the paper, Eppinger, presents four strategies to fix common issues that appear during diagnosis of product development systems. We present them here modified a strategies to improve the PDS.
1. Seek optimal arrangement of activities to reduce rework associated with unplanned iteration
2. Align organization to the activities 3. Reduce information exchanges required to complete each task, achieve this by relocating
parts of tasks or creating broader roles 4. Identify unplannable rework and manage the risk associated with it by assigning the proper
resources to those items
122

6.4 Key Takeaways - Product and Process
The process dependencies in product development are often less clearly stated than in many other
business processes, mainly because there as a number of assumptions and interactions that tend to
be undocumented (Browning, Fricke, & Negele, 2006). Additionally it may often seem that finding the connection between the product and the process to deliver is not always as clear as it should be.
However, the best product development organizations have proven that their ability to have a
process that is well matched to their products and client needs leads to quantum leaps in efficiency and product development times.
1. Fundamental changes to an organizations process must be given time to take their full effect
Process changes do not have immediate effects on the ability of an organization to deliver their work, and must be given time to mature and evolve. Changing the process continually detracts from creating process discipline and creates churn in the product development process. Leadership must therefore create an environment that is conducive to stability and gradual, yet continual evolution of business processes.
2. A concurrent product development process is key to reducing development times
The use of concurrent product development practices are widely spread in the automotive industry, however only few companies have succeeded in benefiting from this practice. This is mainly due to the enormous discipline that is required to follow a process that is dependent on every task being completed on time; a single delay causes enormous inefficiencies during a concurrent process. The enablers for successful use of concurrent engineering practices are: process discipline, nimble and robust decision taking capability and alignment of process to product.
3. Apply process flexibility and rigidity selectively for the PDP (product development process) Rigidity and flexibility in the product development process must coexist for a product development organization to be truly efficient. Selection of where to apply each is an ability that product development leaders must develop to enable their organizations to continually evolve yet reap on the benefits of standardization. Achieving flexibility, standardization and process discipline seems contradictory, yet can be done by finding the unit elements for the process at hand. In product development these unit elements are found at different levels depending on the task at hand, but are important to help us manage the complexity involved in the development of a new product.
4. Ensure that the customer need is kept alive throughout the product development process
In product development the input to the process is generally weak (the customer need), yet the output is strong (our finished product). Because of this disconnect it is easy to deliver products that don't meet our customers needs, and are as a consequence unsuccessful in the marketplace. Keeping the voice of the customer as a strong signal can be achieved through a combination of process and direct exposition of key product development team players to the customer.
123

5. Product development as an information transformation process depends on good transformation and transmittal of information
In product development we must transform the customer need into a design and finished product, and transmit this information effectively between the different functional areas of a company - manufacturing, marketing, finance. In general effective transmittal of information can be achieved through rigorous process discipline and effective transformation by following design methods and rules.
6. Use the process is to serve as a learning tool to deliver better products
The product development process is a key repository of an organization's knowledge for product development. It summarizes the latest official version on how to do good product development, and provides a place from which to start improving. To evolve the product development process we must subject it continually to evaluation and then use hypothesis to propose changes.
As an outcome of analyzing the product and process relationship it is clear that the creation of a
learning organization is a must if one is to improve the product development organization. Use of
hypothesis to guide the direction of the improvement efforts is suggested as a way to achieve
structured improvement. In addition to this the process itself constitutes an excellent repository of
information and must be treated as a living element of the PDS to improve it as required.
124

7 Incentives and Enablers for Product Development
People are the basic unitary element of organizations and must be given the means and motivations
to help the organization achieve its objectives. In product development means take on the form of tools such as software, computer hardware, testing equipment, working environment, etc. The
motivations come from many sources yet the goals provide the individuals and teams with work
objectives. Together, tools and goals provide organizations with the enablers and the incentives needed for people to work efficiently toward a common direction.
Great product development organizations are able to consistently give their employees the right tools and motivations. Tools help boost the potential of the organization by reducing the amount of
time needed to complete a task or by helping broaden the scope of action. Organizations must keep their tool set up to date to maximize the potential of their work force. Using this potential in value added ways for the company is the work of the organizations incentive system. By selecting the
goals to be met and assigning metrics, an organizations leadership can create incentives to direct the efforts of people in the desired direction. In product development organizations, getting the right balance in these two areas requires skillful leadership and experience. As a result to develop a best in class product development organization we must target actions to continually keep
incentives and tools current and relevant.
7.1 The Incentives - Goals
Incentives come from many sources and are critical to determining what people value. Goals are
one of the ways organizations can change what people value by providing direction on what is important to the company. The rewards associated with meeting goals provide motivation to work
toward delivering the company objectives. Although the incentive to work comes from many sources, organizations must deploy goals that are well aligned with the strategic business objectives.
Goals must provide clear direction for all members in an organization. To be effective goals must provide a way to measure progress and a target value (Crawley, 2006, p. L3). The metric and the goal are therefore intimately related, without a reliable measurement a goal cannot be set effectively. When goals are set without an appropriate metric the resulting impact on the
organization is almost impossible to predict. Creating effective direction for the organization therefore requires setting goals that have a clear metric and target value.
Organizations must work as a single coordinated unit to be successful. John Hauser in his paper calls upon goals and metrics to provide coordination in the new world of geographically disperse teams (Hauser, Metrics Thermostat, 2000). For product development organizations that are located around the globe having the right set of goals is imperative when directing distant teams toward a same strategic direction. Good goals must be relevant to everyone involved and their metrics measurable at all locations. An aligned set of metrics and targets can help global organizations deliver their business objectives.
125

Selecting the right metric is one of the key differences between organizations that lead the pack and those that trail behind (Collins, 2001). The right metric allows all resources in the organization to be directed in the best possible way. Organizations continually make decisions and accept tradeoffs between the competing options, the metric and associated goal enable the organization to make these choices in a coherent manner. The best companies and organizations continually make the right choices faster than the competition, and a good metric is a proven way to achieve this.
7.1.1 Goals, Metrics and Targets in Product Development
Selecting the right metrics, establishing a culture that rewards those metrics, and tuning that culture to place the right relative emphasis on each metric are critical tasks in managing a dispersed product development process.(Hauser, Metrics Thermostat, 2000)
Product development organizations must create new products that surpass customer expectations. Leading an organization to achieve this requires goals that are focused on delivering customer added value at all levels of the organization. To guide our selection of goals that are focused on customers, some high level ideas of what we should aim for are presented by Dehoff and Loehr (2007) in their analysis of Toyota's product development capabilities:
* Increase the significant knowledge about your customers' needs. * Incorporated these inputs into your designs. * Provide substantive support to decisions to overruled customer inputs. * Know which of your customers' needs and desires remain unclear at the product
development level.
Goals for product development organizations that are effective should guide us to successfully comply with these guidelines. Selecting the metric for these successful goals can often be one of the most difficult tasks a product development organization deals with.
In product development and engineering selecting real and appropriate metrics requires detailed knowledge of the customer and technical aspects of the product (Crawley, 2006). Often customers will be unable to tell engineers what metric and target will deliver on their need. Instead customers normally provide qualitative descriptions of their necessity (goals) and it is the engineers' job to transform these inputs into quantifiable metrics and targets. This change between what the customer asks for and what engineers can measure and work toward is key to ensuring the creation of customer added value.
Customer needs are multidimensional product characteristics that must all be met to design a successful product. Multiple metrics must be developed to account for these multidimensional customer needs, leading to combinations of metrics and problems with tradeoffs between competing metrics. Metrics in product development also tend to affect several technical areas at once in significantly different ways, making the goals difficult to cascade throughout the
126

organization (Crawley, 2006). Product development organizations must work to define metrics that capture customer needs as simply as possible and are easy to flow down into different functions in the organization.
Good engineering decisions are a consequence of setting the right goals. The metric is the component of the goals that has the most influence and has proven decisive to many organizations. The early design stages are the ones where the selection of an adequate metric has the most influence. Selecting among different solutions at the concept level is largely dependant on the metric used to compare them. In engineering, the use of quantitative metrics makes these decisions highly sensitive to the metric we have chosen. Selection of the right concept and architecture for a product is contingent on identification of a relevant metrics.
Managing and tracking the progress of a product development project requires using metrics. Tracking of metrics during the development of a new product is a must if we want to deliver our project on time and budget (Crawley, 2006). Each of the metrics that are tracked must specify a clear target and a time frame in which to deliver. All progress on the metrics should converge toward milestones that mark significant progress in the project. When tracking and managing the project the differences between actual and expected results help the leadership team decide where more resources are needed.
Metrics can absolute, marginal or probabilistic, with each approach having pros and cons (Crawley, 2006, p. L8).
* Marginal -> X% improvement in * Absolute -> X value of * Probabilistic -> X value of with 90% confidence
The selection of either of these approaches to metrics is based on what our goal is. Continual improvement for example goes well with marginal metrics, while cost objectives go well with absolute measurements.
An ideal organizational metric in product development would be able to combine the effects of cost, schedule, risk and the benefit/performance (Crawley, 2006). However, developing a metric like this is a difficult task and we should at least make sure that our organization meets current industry practice that uses a benefit/performance and cost metric, while separately assessing schedule and risk. Use of a metric that combines all elements could provide an product development organization with significant benefits, allowing improved decisions and project tracking.
For product development projects, the multitude of goals can create confusion when attempting to make decisions. Organizations must decide on one or two high-level goals and their metrics that will guide all actions. The remaining goals must be then be classified by their importance from live or die goals to those that are just nice to have.
127

7.1.2 Using Goals to Modify Organizational Behaviors
They want to fine tune their culture so that each product development team acting autonomously (and in its own best interests) takes the actions and makes the decisions with respect to these metrics in a manner that maximizes the overall long- term profit of the firm.(Hauser & Clausing, The House of Quality, 1988)
Goals change people's incentives and therefore modify their behaviors. One thing that is made clear
in many sources of organizational change is that one of the first items to be reviewed is the
development of goals that are value based (Dehoff & Loehr, Innovation Agility, 2007). Without the proper goal system in place it is difficult to leverage the organization and resources will be spent
attempting to move the organization in a direction that is not compatible with their value system.
Modifications to behaviors, the value system and goals must therefore be conducted toward
achieving successful organizational change.
An example of the relationship between goals and successful product development organizations
can be seen with Toyota. At Toyota the goal system has been developed such that it directs the
company toward constantly improving its added value equation by widening the gap between
product value and cost (Dehoff & Loehr, Innovation Agility, 2007). To achieve this effectively Toyota has done a significant amount of work on truly understanding what the value of their product is in
terms of the customer. They have focused on ensuring that their upfront conceptual designs
articulate the customer value proposition as clearly as possible and on delivering products that are
faithful to this understanding of the customer. The way Toyota has focused their organization has
helped them develop products that are highly successful in the market, how they have selected their
goals has been critical to this achievement.
Setting goals that are contradictory can drive organizations to innovate and make substantial
improvement. Within Toyota's ambition to better serve their customers they have not avoided
setting ambitious and sometimes contradictory goals. The objective of setting goals in this manner is to drive the teams to pursue innovations that are capable of delivering what is regarded today as
infeasible. Such is the case of the Toyota Prius and the Lexus, both of which re-wrote paradigms in
their own right (Liker, 2003) (Dehoff & Loehr, Innovation Agility, 2007). Product development organizations that strive to become world-class competitors will need to understand and use seemingly contradictory goals to go beyond their current state.
Value added items that are overlooked are often done so because the overall program focus and goals have been incorrectly set. Engineering teams can easily start the conceptualization of a new
product by focusing on cost instead of improving the value proposition for the customer. This leads the teams to overlook the aspects that truly drive value to the customer (Dehoff & Loehr, Innovation Agility, 2007). Good goals have as a mission to lead organizations toward focusing on customer added value.
Goals and metrics are heavily influenced by the culture of the organization they are used in. No two organizations can use the exact same goal system. Every organization must therefore work to
128

develop goals and metrics that are adequately matched to their own culture. Some organizations will need additional reinforcement to enforce process discipline, while others may need to
incentivize creativity. How people perceive that the goals are valued within the organization is as
important as the goal itself.
The development of metrics to balance stretch goals between cost, performance and quality in a manner that drives customer value is necessary for product development organizations (Dehoff & Loehr, Innovation Agility, 2007). The success in this area depends both on the ability to set the goals but also on the ability of the organization to translate the goals into solutions for the product.
Correct application of a strategy of aggressive goals and a receptive culture can lead to quantum leaps in the products developed.
7.2 Enablers - Tools
In developing the metric thermostat we recognize that there are hundreds of detailed actions, such as the use of the house of quality and the use of robust design, among which the product development team must choose. We also recognize that they will act in their own best interests to choose the actions that maximize their own implicit rewards as determined by the metrics. Management need not observe or dictate these detailed actions, but rather control the process by establishing the culture that sets the implicit weights on the metrics. The thermostat works by changing those implicit weights.(Hauser, 2000)
Organizations seek to minimize the effort we need to complete a task to improve their efficiency. Improving efficiency can be done by providing enablers that reduce the work required to complete a task. These enablers can be generically called tools. As described in the Merriam Webster, 'tools' is the generic name given to an apparatus, instrument or something that aids in accomplishing a task (Merriam-Webster Dictionary). In product development organizations some of these are: enabling IT systems, virtual design tools, instruments, and many others. For managers and leaders selecting tools that will increase the organizations efficiency and effectiveness is a tough job.
In product development organizations successful tools depend on both the disposition of the management to support them and the discipline of the engineering work force to use them. Tools can be great when well implemented, but they can also become huge wastes of money. Involving the users in the selection of new tools and achieving management buy-in to their deployment increase the success rate of tools. Many examples where these two simple rules have not been followed exist, and the results are never encouraging.
To increase a tool's effectiveness and success, one should make sure that the tool follows the process. Tools are enablers and as such they should not dictate our selection of process. However in many cases tools modify the process because they shorten cycle time dramatically or have some other effect. In these cases we must ensure that our process maintains integrity with the new tool.
129

Tools that can adapt to a companies process are easier to assimilate and better at improving efficiency.
In product development the availability of management tools to improve efficiency is less than in
manufacturing.
Tools and processes to help redesign complex activities like product development are
less mature than the TQM methods that proved so effective on the factory floor. (Sterman, Repenning, & Kofman, 1997, p. 520)
Product development organizations are therefore continually challenged to find and develop better
ways to work on their own. Additionally, tools in product development are less likely to be universal
amongst different organizations. This means that product development organizations must work
more than manufacturing operations to bring tools that can aid in improving the organizations output.
A tool that has become more common for the design and study of product development processes
is the DSM matrix. This tool is of importance to organizations as it 'represents information flows
instead of work flows'(Eppinger, January 2001). This makes it invaluable to understanding the relationships between activities, and provides a visual aid to the redesign of an organization.
Because of the characteristics that the DSM matrix displays it is a desirable planning tool for product
development. Application examples in different organizations have met with great success.
Organizations such as NAC that are continuously developing new cars have developed established
processes and already know the tasks needed to develop a new car. However identifying the
information needs of each of the tasks/activities is a major problem, and one that the majority of a company's management will be unable to answer. Having said this, it has also been proven that in
general managers and engineers will have a better understanding of what they need coming into
their process, than what they are expected to deliver(Eppinger, January 2001). From this we can gather that in the process of mapping a process within an organization, focus should be on asking
people what they need to complete their job. 'Software tools are not always the right solution, and additional spending on information technology or CSCW (computer supported cooperative work) systems does not compensate for poor management.'(Maier, Eckert, & Clarkson, 2006)
Technology and good management complement each other and it is important to find the right level to intervene and adjust. (Maier, Eckert, & Clarkson, 2006)
Perhaps the most important and least considered factor in the design of information storage and retrieval systems is the user of such systems.
A system that is designed to require education of the user, is one meant for the future. The user of
today requires systems that are able to serve presently (Herner, 1959). Selecting the right tool for managing requirements involves intimate knowledge of the process the requirements are involved in. Tools and processes must compliment each other to maximize the effectiveness of both tools
130

and requirements. As such we must focus our effort on analyzing the process in order to choose the tools that most effectively support our needs. Extensive process analysis techniques have been developed by authors such as Blanchard, 2004; Negele, 1999.
For most cases it is quicker to change the tool that manages the requirements than the process. It is because of this that in many cases we find companies routinely updating their requirements management tools without success. These continual changes can lead to multiple systems being used at the same time throughout a company creating duplicity and/or absence of requirements. These conditions generate rework and generalized engineering inefficiency.
An example of this was observed at North American Car when inquiring about the requirements and target setting tools in use. It was found that different locations, specifically North America and Europe, used different tools to manage the cascade and selection of requirements for new vehicle programs. Although for a long time this situation was acceptable, increasing market pressures and tougher safety regulations have increased the required interaction between the engineering groups on both sides of the Atlantic. The need for increased interaction required flawless information transfer and excellent communication. Even though the engineering teams were working aligned, the incompatibility of the tools used to develop their work created the need to deploy a team dedicated to solving these core incompatibilities.
7.2.1 Prototypes as Learning Tools
Going to the source has been one of the main lessons learned form observation of the Japanese engineering organizations. It is repeatedly mentioned that being able to be in touch with the product is critical to success. We can attribute this to the fundamental psychology of learning. When learning knowledge is gathered through all of our senses and it has been seen that effective learning can be encouraged by providing inputs to our brains via more than one of our senses. Smell is the most primitive sense, followed closely by touch. It has been proven that there are significant connections between learning and these two senses.
Building physical prototypes is a resource intensive task. Unique prototype parts must be manufactured and each vehicle is more akin to a handcrafted watch than to a production vehicle. This has driven a huge push towards reducing prototypes counts and increasing the use of 'cheaper' analytical tools such as CAE (computer aided engineering). Recently industry leaders in transitioning from physical prototypes to virtual prototypes have stumbled upon significant roadblocks that have had enormous cost penalties. This leads us to believe that we must revaluate what an optimum balance of analytical to physical validation is required.
Having defined that our main objective is increasing added value to our customers we must evaluate the cost, time and quality impacts of choosing either physical or virtual development. Physical prototypes enhance the understanding of technical problems and can positively influence team interaction.
131

7.3 Key Takeaways - Enablers and Incentives
For product development leaders it is critical to understand how to best incentivize and enable their
organizations to deliver new products that are successful in the market. Incentives are particularly difficult to define for product development organizations as they must cope with the complexity that arises from technical and people problems. In parallel the enablers - tools - can be deceptively simple but have profound effects on how efficiently an organization can function.
1. Aligned goals enable delivery of strategic objectives and the coordinated work of global teams
The importance of setting goals that are well aligned at the individual, team and organizational level is more than often underestimated. Goals allow product development organizations to track their performance, but more importantly to align their work direction. In global product development teams aligned goals acquire an even greater importance as they will act as a glue to keep geographically distant teams synchronized at all times.
2. Effective goals need a metric, target value and a delivery date
Creating effective goals is contingent on the ability to select the right metrics target values and delivery dates. As a whole these three elements can create a goal that correctly incentivizes the organization. Amongst the three elements selecting the right metric is the most difficult task; and in product development requires intimate knowledge of the customer and the technical aspects of the product. Additionally selection of the right metric is key to organizations as it will create an enormous competitive advantage, enabling the organization to take decisions faster than the competition.
3. Product development must strive for customer oriented goals
Ideally product development goals must strive to become fully customer oriented to ensure that the products that are developed meet and exceed customer expectations. However in product development this is no easy task as it requires taking multidimensional customer inputs and transforming them into technical goals for the organization. In this sense the ideal metric for a customer oriented goal can measure cost, schedule, risk and performance to benefit ratio in terms of how it impacts the customer. Because a single metric can often lose the required granularity, a set of a few key metrics is normally preferred at the product development level.
4. Use contradictory goals to set challenges
The contradictions of today can become the product successes of tomorrow. Organizations that have mastered the art of setting aggressive and seemingly contradictory goals have managed to develop products that meet the real needs of customer through game changing breakthroughs. Examples of effective utilization of this strategy can be found in many industries, however, in the automotive industry Toyota has made this strategy one of their key competitive advantages.
132

5. Tools must follow and help deliver the process
The complex nature of product development makes selecting and using tools to improve the performance of the organization more difficult than in other functions. One of the key issues with selecting a new tool for the organization is the imminent danger that it will begin to lead the development process, instead of enabling it. Tools can quickly begin to dictate how an organization works, defining the necessary steps to complete a task instead of only supporting the delivery of the product development process. Good tools must be transparent to the product development process and facilitate the work required to complete a given task.
6. Tools will not solve inherent structural problems in the organization
Tools are enablers, and not solutions to process or structural problems in an organization. Leaders in an organization must take care to identify when implementing a tool will help and when other measures are needed. Faulty processes or structural problems in an organization can only be patched by a tool, but will not be solved. The cost of implementing new tools in product development and the general imbalance a new tool creates in the organization makes selecting tools with care key to success. Examples of incorrect tool selection and implementation are many, as there have been many general managers that have grabbed tools that are in vogue attempting to improve the organization and have only succeeded in further reducing its efficiency.
7. Physical prototypes used as learning tools
Physical prototypes have been traditionally seen as mainly testing and validation means, however they also constitute a key learning tool for product development organizations. Physical prototypes significantly increase the understanding engineers have of their parts and sub-systems enabling them to increase the robustness of their designs early on. Correct use of prototypes can also help reduce manufacturing issues during launch and improve the normally difficult relationship between engineering and manufacturing.
The tools and the goals that are used in an organization must be aligned with an organizations underlying architecture to ensure that they work in synchrony with the overall system. The selection
of key takeaways highlights the supportive, yet critical nature of these items.
133

8 Case Studies in Product Development
Design of a new product development system requires both academic and practical industry knowledge. This chapter focuses on the practical aspects of product development, and presents a series of seven real world examples that show the influence of various aspects of the product development system on the development of new products. Prior to this, chapters four through seven have presented a mostly academic review of the main structural elements (and one character element) of the product development system. Some of these academic reviews have included brief real world examples from the automotive business to help support some of the main ideas. However, additional support from examples of product development in the industry must be gathered if we are to successfully design a product development system. This chapter will therefore aim to complete our view point of product development by looking at the industry side of development and identifying what the common pitfalls derived from system issues are.
In the first chapter of this thesis we present an example of how introducing a new material to a vehicle became stalled by what seemed in the aftermath a minor problem. The following seven examples are also cases of product development problems that should be absent from the product development system we are designing. In the material example from chapter one, the key to solving the issue was to look at the problem from the full system level, and provide an accurate assessment on the true performance of the material. Looking back it became obvious that the engineering and purchasing teams had never really worked together as a team to solve the problem; it actually was almost as if they had been fighting each other. Increased emphasis on communication, team work and intense focus on customer needs could have improved the odds of finding the solution faster. Analysis of the trends in these conclusions then suggests that in this example all the elements of detail in the product development system had worked well - toxicology testing, vehicle evaluation, purchasing agreements with suppliers. This however did not help the team, and rather the problems and solutions that we present had their root cause in system problems. Each of the following examples will describe a situation encountered in product development, identify what the problems at the time were, provide insights and then identify what the architectural considerations for the PDS should be.
In all the seven examples presented the author of this dissertation was directly involved in the problems and their eventual solution. Having participated in the System Design Management program a system approach was sought to solve all of the problems. For all the examples presented here, the end result of applying systems engineering principles was positive, and developing a holistic view of the problem allowed for their efficient resolution.
134

8.1 Alignment of Process Timing - Development of Program Derivatives
SITUATION DESCRIPTION
In the automotive industry a common practice is to reuse parts, subsystems or whole vehicles to develop new vehicles. This practice - in theory - reduces the engineering work, tooling and overall cost to bring a new vehicle to the market. In this example a full vehicle was being developed for a high end market (base program or car) and from this we were tasked with the engineering of a low cost derivative for sale in other countries. The low cost derivative had an independent engineering team that was located in a different country and was tasked with all the engineering and development of changes to the base vehicle required for sale in other countries.
Being a major program the base vehicle required a significant amount of development and engineering work and it was a known fact that as all development processes the design would go through many iterations, changes and redesigns before reaching its final form. As a result of this, the low cost derivative team chose to schedule all its engineering milestones and prototypes events four months behind the base program with the intention of using designs that were closer to the final result as the base for the modifications. In theory this would help us reduce the amount of churn that would reach the derivative team and minimize rework. This approach seemed adequate in theory, yet a series of unexpected issues resulted from this decision. Of the issues that resulted from this decision the following two areas were the ones that had the greatest trouble.
1. Prototype building - issues related to part ordering, supplier support, base team support 2. Engineering support - lack of base program support for joint activities
PROBLEM 1: Prototype builds
For the development of the derivative vehicle, two phases of prototypes were built to aid in the development process; in the same manner as the rest of the program, these prototype builds were phased behind the schedule of the base program by four months. When the time to order parts for the first batch of prototype vehicles came, we ordered the latest possible part levels with the intention of building and validating the local changes with the most advanced part designs available.
From the moment the first part order was submitted it became clear that something was being done wrong. Ordering of the parts was a major issue, which we explain in detail in our next example in section 11.2, and suppliers would provide lead times for parts that were unacceptable for successful completion of the program. These challenges were solved and parts were shipped by supplier only marginally late for the prototype construction; yet the parts that were secured were in their design far from what had been expected. Most of the issues with the parts that had been received appeared while trying to assemble them as in some cases they would plainly not assemble. As an example we received brake lines that could not be threaded into the ABS (antilock braking system) module; thread size would be 8mm coarse thread for the female on one end and we would have a 10mm fine thread male on the other end. Many problems such as these surfaced and finishing the
135

first series of prototypes became a nightmare for all involved. The main problems that the team
encountered were the following:
- Parts of different engineering levels that would not assemble - Unexpectedly long lead times for parts would delay build
Toward the end of the first batch of prototypes the situation was analyzed and it was found that a
series of mistakes had been made that had led to these problems. Regarding the part levels, it was
found that either the supplier had provided parts of levels other than the one requested or that the
engineers had not been able to identify the right sets of parts needed to create the assembly. The
unexpectedly long lead times were found to be driven by suppliers working on a different level of
prototypes parts or because they provided the due dates for the next prototype batch that was not
dues for another 6-8 months.
PROBLEM 2: Engineering support
Moving to the second item, engineering support, lack of alignment on engineering milestones caused major issues for the derivative team. Development of the low cost changes required that the low cost team interact with the base program and share information in order to meet the new
requirements. However, the difference in timing for the programs meant that while the base
program engineers were working on launching the vehicle at the plant, engineers at the low cost team were still finishing validation. As a result, neither part of the team was able to work in synergy and was therefore much less efficient than they should have been. In one example that shows the
disconnect that the difference in timing brought about, the low cost team had decided to use a
different rear braking system than the base program; as a result the parking brake cables needed to
be routed differently and used a series of holes that were available on the chassis to hold everything in place. Very near the start of the production for the vehicle it was found that the holes that had
been selected by the derivative team had been deleted from the chassis in a cost reduction action
sought by the base program. As a result much more work than had been planned went into catching up and correcting the change.
INSIGHTS
Selecting the phasing between a base program and its derivatives is key to facilitating the work
between the two teams. In the example we have presented, the phasing of four months between
the programs created additional work and did not achieve the expected results. Therefore two solutions are proposed.
1. Align the timing of both base program and the derivative to allow for concurrent development * Pro - all development can be complementary, best common solutions can be found,
prototype ordering can be simplified * Con - greater difficulty for coordination, development cost of using earlier prototype parts
for building the derivative prototype vehicles is higher, churn can be greater if the teams do not coordinate well
136

2. Increase the time phase between programs sufficiently to ensure that the development of the
derivative is done on a production ready design * Pro - All development prototyping is done on 'cheap' productions vehicles, there is
extensive knowledge of the vehicle systems * Con - Less possibility of using similar resources for development and validation purposes,
engineering team from base program no longer works on the same program or issues, engineering support could be very low
Looking at these results, it seems that although the proposed alignments might have advantages over the timing overlap that was used in this example, there are other factors that weigh into how
the different engineering programs overlap - products from the competition, manufacturing facility
usage, production parts availability - to name a few. Because of this, it is proposed that
development teams must analyze their timing with care and try to avoid the issues as presented
here by taking preventive actions.
For the second batch of prototypes we had learned a hard lesson, and therefore we worked with the
base team to pre-order their parts well in advance of when they needed them to have a full set of
parts ready for building the prototypes further along. This way the teams helped each other and
made the most of having an extended support group.
Finally a lesson that also became clear later on was that for a great part of the team working on the
base program the derivative was an unknown for a long time. People working on the derivative
thought that everyone else was aware of their existence and needs, but this was hardly the case,
and many problems could have been avoided by making sure that everyone was aware of the
derivative development effort. Ensuring that the presence of a derivative team is known, is a first
step toward achieving synchronized development efforts.
PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
Throughout this example all the individual aspects of the team worked well and as designed. However their combination was unfortunate, and in this case driven by a defective process. The
corporate product development process provides a way to incorporate lessons and detailed
interaction summaries to our work, and avoids us from reinventing the wheel; yet it does not by
itself deliver on all the expectations. Process design and adaptation is a critical task; one that either
synchronizes all events for a project with the rest of the organization, or de-phases them as was the case here, bringing chaos to the development efforts.
What we did to solve the problem was to align the timings for subsequent events, and then for
development efforts after this, always account for the interaction of timings, resources and activities. Getting the process to synchronize, must never loose track of the value creation events of the product and all work dictated by the process should be directed at meeting them with the utmost precision. Finally efficient global product development systems depend on the efficient interaction amongst their constituents around the world. A flaw to align processes to maximize overall efficiency is apparent in this example.
137

8.2 Commonizing Tool Usage -Ordering Prototype Parts
SITUATION DESCRIPTION
The building of prototypes requires having congruent sets of parts engineered and built; the sum of
this effort allows engineering teams to build full vehicle prototypes. Achieving the level of
engineering required to build a full prototype is important to development teams as it ensures that the overall project is on track to meet all technical requirements. It also provides the team's leadership group some indication that of if the overall team effort is moving in the right direction or not. Large vehicle programs require many prototypes in order to validate the entire set of requirements; sufficient prototypes are needed to provide the necessary resources for effective development efforts. Smaller development programs require fewer prototypes and in general only a few vehicles are built to conduct development (3-5 vehicles). The number of prototypes, however, does not reduce the engineering effort needed from the team to successfully build them.
This example is an extension of 11.1 and therefore also subject to the same phased timing schedule difficulty, and the problems that were described above. Here however we look at the specific manner in which the prototype vehicle parts were ordered and the problems and lessons that can be learned from this aspect of the project.
The development program being analyzed was one of the largest ever undertaken by the organization in developing the derivative truck. There was therefore little experience in the organization as to how to build prototypes of such complexity and the processes that were involved in doing so. In parallel, the base program was building at least ten times more prototypes and had substantial experience in building prototypes. The smaller organization found itself having difficulties to order the right sets of prototype parts and build the prototypes as needed. From this experience the main problem identified relates to the IT tools used to support prototype building.
PROBLEM
Ordering parts for prototypes is done for each and every development program. The base program had developed tools that allowed for automatic ordering of parts and tracking (thousands of parts), and also had a separate system for ordering the extra few parts needed to develop the vehicle (dozens of parts). An inability on our behalf to accurately portray what the needs of the organization were led to using a system designed to order individual items to be used to order the thousands of parts needed for the full vehicle. As can be imagined in committing this mistake the team generated themselves much extra work.
Many of the parts that were needed to build the prototypes were the same as those used in the base program, who was ordering parts almost by hundreds. Because of this, when the small (one or two piece orders) were received from the derivative team they were almost always dismissed and seldom did the part orders get fulfilled on time.
138

In general there were severe problems relating to how prototype part orders were fulfilled. These issues then cascaded to the prototype builds that would begin to lag behind schedule. This relatively simple problem can be seen to have two aspects that are worth noting for future work.
- Incorrect use of the tool led increased workload - Lack of understanding of available resources and tools reduced the opportunity for synergy
The reluctance of the team to ask for help and adopt the right tools was partially a lack of knowledge but also a consequence of the difference in cultures between organizations. The exact features of the culture that had an effect were not understood, but it almost seemed as if a curious for of engineering pride got in the way of asking for help.
INSIGHTS
In this example a simple IT tool that helped place prototype orders would have made a significant difference to the efficiency of the derivative team. Because of the smaller size of the program it could have been seen as an acceptable situation; yet by looking ate the overall system collaboration with the base program was achieved and the programs became aligned in process.
Tools must be used with care. Application of the wrong tool can lead to significant issues, and prevent the team from seeing what should really be happening. In this case the scope of the tool was inadequate and rendered the process almost impossibly difficult to manage.
For this program, the best compromise at the end was to align the timings and then use the resources of the base program to help order parts for the derivative team. This arrangement had many advantages first by keeping the orders to the suppliers clear, second improving the overall leverage of the OEM and finally it helping promote engineering alignment of the base and derivative teams.
Several action paths could be taken to alleviate this particular situation, but as general guidance the following items would have kept this problem from happening.
- Promote use of corporate tools and conduct sanity checks during their incorporation to ensure that scope and purpose of the tool align with the organizations need
- For common tasks share resources amongst development programs to reduce cost and complexity
PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
The product development system called for little to no interaction between the engineers from both teams, yet it was through this work that the problem was solved. It is necessary that the PDS both encourage individuals to work with their counter parts as it is important to have involvement of engineers during the definition stages of a project.
139

As part of the effort to solve the problem we worked on improving the relationships amongst engineers and generating awareness of the program to the team counterparts. The links created through a series of planned visits we made to the engineering team in the US over a six month period created relationships that allowed the team to solve the issues at hand and resolve other problems that surfaced further down the road. Architecture of the PDS should drive teams to use the right tool for the right job. Additionally creating synergy is a key aspect of the architecture.
8.3 Requirements Development - Global Market Needs
SITUATION DESCRIPTION
Definition of requirements for new vehicles is unique for different markets around the world. They must account for the differences in customer usage profiles and regulations imposed by different countries. In more general terms, requirements provide companies with a repository of lessons learned, best practices and general engineering knowledge. However, vehicles and their environments change and so must the requirements that are used for their design. In the following example the OEM had requirements that applied globally and then a subset of additional requirements for each market. As an engineer I had the opportunity to participate in the engineering team of one of the affected markets. Our assessment of the requirement was that it was far too strict and that a look at the competition showed that it was unnecessary to submit the vehicles to such stringent tests.
A team was assembled to look into the requirement in detail and push for an update to the requirement so it would better represent the market needs. The team worked on this task for over two years and we were unsuccessful at changing the requirement, but it is in the work done during this period that we want to focus this example. The requirement was mainly dependant on three variables and their interaction: overall vehicle speed, operating temperature and pressure. With this knowledge we set about gathering information to support our recommendation to change the requirement.
PROBLEM
Requirements are normally managed in a centralized fashion and go through extremely rigorous and structured approval processes for updates. This provides the engineering team with reassurance that the requirements are accurate to the best of the company's knowledge. Therefore, changing the requirement we had in hand would require a solid case to prove that the change in the requirement had solid bases.
The requirement was affected by the three variables described and choosing the right approach to the problem and what to concentrate on cause us much difficulty. Initially the method used was to cover the whole spectrum of variables and their possible combination. This provided us with the data necessary to prepare an informed request to change the requirement. The extent of work that this approach entailed meant that the team spent time even on weekends working to gather the
140

data. Analysis of the data only proved that it was insufficient in quantity and that we needed more evidence to generate a sufficiently strong argument to represent our case.
Relationship with the central council (in charge of the requirement change process) generated tensions within the team. There were disagreement in the team as to how the relationship should be managed and as a result for a long time the interactions were fruitless.
INSIGHTS
Product development teams in large companies must to follow a variety of requirements that have been established as part of corporate guidelines. It is the responsibility of the engineer to identify the requirements that apply to their work and form these purge those that no longer apply. However it is also the responsibility of the engineer to investigate and prove why the requirement needs to be removed. To accomplish this a strategy must be developed, which in our example, our team was unable to define with sufficient celerity.
Developing communication links amongst the team members and allowing for a feeling of trust amongst them was critical. As recommendations:
- Use of a dedicated set of systems engineers to solve disputes at the corporate level would have helped clarify the issue and direct the validation efforts
- Challenge requirements to advance engineering is necessary, yet discipline must be followed
PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
Requirements are an essential part of a companies product development system and it is through them that many of the lessons for developing new products are cascaded through the product development ranks. Ability to manage requirements in an efficient manner and transform them into true direction for the product development system is critical for the growth and development of PDS.
Technical knowledge and problem resolution capabilities are important in all product development activities, the example presented here demonstrated a lack of understanding of the problem at hand and the extra work that brute force engineering will bring to the team. In our team every individual was technically qualified in their area and the tests for each aspect variable an interaction of the requirement was done without flaw; lack of understanding and vision of the system above made it finding the right approach difficult.
The requirements management system of a company must be such that we are able to both control the addition and elimination of requirements, but must also aid in making the their use more efficient.
141

8.4 Engineering to Manufacturing - Launching a New Vehicle
SITUATION DESCRIPTION
Taking a finished design and implementing for mass production is the last step in the execution of
the product development activity and one where value is often lost. Good designs are nothing without a manufacturing process that is in control and can reproduce the expected result hundreds
of times a day. The process of taking the design into production is called 'launch'. This phase within
product development should be without major issues if all engineering work has been done correctly, however more often than not many issues arise during this period.
For the launch of a new vehicle it was discovered upon building the first units on the assembly line
that parts such as the HVAC (heating, ventilation and air conditioning) unit could not be assembled and that other vehicle components were arriving at the plant incomplete. Work was done immediately to solve these issues, and subsequent analysis highlighted three problems.
1. Late changes 2. Virtual tools capability 3. Supplier and engineering collaboration
PROBLEM 1: Late changes
Late changes to the design of different parts had occurred during the final stages of the
development process of the vehicle and as a consequence had generated two problems. One was that a series of parts had not been fully validated in the vehicle, and the second was that suppliers
were still struggling to catch up and understand what they were being asked to deliver.
For the situation where the parts had not been fully proven out on the prototypes the main reason was tracked to (in many cases) a change in the assembly process. Validation had been done using a non standard method for assembly, and upon trying to assemble at the plant with a different process new issues came up. The first round of designs had met all the assemble requirements but
the last minute changes had meant that not all validation had been as rigorous.
Suppliers were also struggling to send the right parts to the plant. The late changes had made tooling modifications necessary and timings for part delivery had been affected. In some cases parts with previous design levels had already been made and even with instructions not to use them on
the production vehicles mistakes in shipping and handling had them mixed up for some time.
PROBLEM 2: Virtual tools capability
Use of computer aided design has revolutionized engineering, but for some specific examples there is still nothing quite like having a physical part. In this launch, many issues came up for the rocker panel inner molding; this molding provides an interface between the carpet and the door seal. Assembly of this molding was extremely difficult and in many occasions would result in a molding that would break on assembly and consequently dislodge itself.
142

The design of all the parts had been done in a CAD software, but because the molding had interfaces that were compliant (rubber and carpet) certain rules for the deformation of each were followed to that the final design would work. However the rules did not work as expected and assembly issues surfaced. To some degree the capability of the CAD tool had been overestimated, and as a consequence physical validation had not been conducted with sufficient care.
INSIGHT
The following are a few lessons learned from the launch experience described.
- Involvement of manufacturing in the prototype builds helps reduce churn further down the road
o Use the actual line workers, help make the process real - Prototype builds help visualize large problems - Movement into more virtual design required increased care during the first build phases to
make sure that interfaces work - Provide updates to virtual design rules to improve the process of virtual design
PROBLEM SOLUTION AND PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
Late changes are the final element in a series of delayed decisions and processes. In order to avoid these issues in a systematic manner, focus of the team must be primarily toward the delivery of the finished design (Engineering Sign-Off event). Using this focus the team can then work back to the pending tasks for today and prevent late changes.
The product development systems of the future will have increased virtual tool support. We must be able to accurately asses the capability of our virtual tools and correlate their results to the real world. Delivery of parts that can not be assembled to the plant is unacceptable. The PDS must ensure that the product design can be built to design intent.
In the example shown my role became to ensure that all components that affected interior noise in the vehicle were properly installed and met design specifications. This work is routinely done, yet the difference was that intimate linkages to the part owners and official vehicle evaluators were created to deliver the vehicle as expected.
143

8.5 Suppliers and Engineering - Emissions Requirements and Fuel
In today's global economy companies strive to provide customers around the world with products that meet their specific needs. Development of a new diesel truck for various markets that used diesels with varying amounts of diesel presented an interesting supplier and engineering issue.
SITUATION DESCRIPTION
During the development of a new vehicle it is often required to use almost the same vehicle in completely different markets. These differences in markets arise either from consumer usage profiles that vary with geographic location and infrastructure development, from regulatory concerns which vary from one region to another or from other environmental factors that have influence on the vehicles. One approach to solving this problem would be to develop different vehicles for each market, however under the current manufacturing constraints that require huge volumes to make business sense out of buying tooling this would be infeasible. What is done on an ongoing basis is to develop vehicles for the most demanding market and then systematically prepare the vehicles for the other markets.
Most countries around the world have a need for work trucks, however use can vary greatly. In developing countries trucks are used mainly for work tasks with the owner of the vehicle and the operator normally being different people. Owners of a work truck will place more importance on load carrying and other work related functional attributes than on luxury related items, such as those demanded in the US market. In addition to this, emissions regulations also vary between markets, with developing countries historically lagging behind the US (EPA - Environmental Protection Agency) or European regulations by one or two generations. Improvement in emissions regulations has advanced quickly in Europe and the US; but this progress has required changes in vehicle hardware, software and fuel quality.
Emissions Component Requirement Level PM 0.01 g/bhp NOx 0.20 g/bhp2
NMHC 0.14 g/bhp Table 8-1 EPA 2007 Heavy Duty Truck Diesel Emissions Standards (DieselNet)
For diesel vehicles only better fuels can allow emissions standards to advance. In the US the current emissions standard being used for 08500 trucks is the EPA2007 emissions3 [Table 4-1]. This standard focuses primarily on lowering the PM (particulate matter) levels and drastically reducing
2 "Very few engines meeting the 0.20 g/bhp-hr NOx requirement will actually appear before 2010. In 2007, most manufacturers opted instead to meet a Family Emission Limit (FEL) around 1.2-1.5 g/bhp-hr NOx for most of their engines with a few manufacturers still certifying some of their engines as high as 2.5 g/bhp-hr NOx+NMHC" (DieselNet) 3 Signed on December 21st 2001 the EPA 2007 regulations call for emissions and diesel fuel standards.
144

the NOx (nitrous oxides) content for the exhaust emissions. In addition the standard calls for diesel fuels to contain less that 15ppm (parts per million) of sulfur - down from the previous 500ppm sulfur diesel in the US.
2007
20 1.1 g NOx avg- 2.0Steady State o.olg PM Test 2010
NOx + HC o2 g NOx avg 0,01 g PM
15 - . NOx 1.5 Tr(UnrguatedsintTest Useul ife
NOx 290K 435K
. N O x CD Transtt &
110 + Steady State CO Oct-02 Jan-04 1.0 z FPM
0 (Unregulated)
SNOx I N + M NOx NM .C
Consent Decree
-1 o ... --a 1. -- .L _ .L - -- L -- ! , ..... ..... . ........ ILL I , , i , J. ... ., O--
1970 1975 1980 1985 1990 1995 2000 2005 2010 Model Year
Figure 8-1 Historical diesel emissions standards progression through 2010 (Detroit Diesel)
For diesel engines, meeting the EPA 2007 standards presents conflicting requirements; normally
lower PM means that we need a hotter combustion. On the other hand, high combustion
temperatures increase the generation of NOx. Reaching an adequate compromise of therefore
becomes a serious technical problem for OEMs.
The technical problem thus resides in being able to eliminate NOx, PM or both at the same time. To
this day, elimination of NOx particles in the exhaust system has been difficult, with only very recent
success achieved using urea as a SCR (selective catalytic reducer) and unconfirmed rumors of a successful Nissan catalyst that does not require urea for working. On the other hand, particulate
matter (PM) are in essence a very fine dust, and can therefore be filtered out from the from exhaust gases; the devices used to filter PM are called DPF (diesel particulate filters). Given this situation the automotive industry has for the most part solved the emissions problem by controlling the amount
of NOx generate during combustion and then filtering out the extra PM that has resulted from
having conducted colder combustion process. Through this somewhat non-intuitive process of
generating excess soot, that can then be filtered the industry has effectively met the stringent new
emissions standards.
As we have stated, within the engine NOx is controlled by means of lowering the temperature of the
combustion process. One of the most effective ways of doing this is by reducing the effective mass of air+diesel that we burn in every combustion cycle by using EGR (exhaust gas recirculation)4 to
4 EGR (Exhaust gas recirculation) is a system that allows exhaust gases to be redirected to the intake manifold so the engine can admit clean air plus exhaust gases and reduce the overall combustion temperature. Some EGR systems cool the exhaust gases before allowing them to reenter the combustion chamber. (Detroit Diesel)
145

feed exhaust gases into the combustion chamber. When we do this we effectively reduce the air- fuel mixture volume that we allow the engine to ingest in each intake cycle and thus have generate less thermal energy during each cycle. This system has been used in some or other form for many years; however the % of exhaust gases that are recirculated has normally been in the 15% range. With the new emissions regulations for NOx this number has to be taken up to around 30% in order to meet the strict regulations. With this amount of exhaust gases, we generate a significant amount of PM.
The filtering of PM is achieved by using the DPF (diesel particulate filter) which is a ceramic honey comb structure that traps particulate matter by forcing exhaust gases through the porous ceramic matrix. Filtering seems straight forward enough but doing so for thousands of miles means that the filter is continually getting filled up by PM from the exhaust gases and it eventually plugs up. These DPF's are normally expensive exhaust system components that are infeasible to be changed during normal vehicle tune ups and that will continually degrade the engines performance with every extra bit of PM that gets trapped. Because PM is in essence soot made of carbon the solution to this problem has been to burn the residue that is left in the DPF. The temperatures required to do this efficiently are around 650C, which are higher than what is normally found in the exhaust system. Increased fuel is therefore provided to help burn the PM and clean the system.
POST-DPF SAMPLING SECTION
SHORT SAMPLING SECTION
LONG DIESEL BY-PASS SAMPLING PARTICULATE JUNCTION SECTION FILTER
DIESEL OXIDATION CATALYST
CONNETION TO TURBO-CAROGER OUT MANFOLD
Figure 8-2 Generic diesel exhaust system layout with a catalyst and DPF (Flow Grid Consortium)
All of the technical problems and descriptions to this point correspond to a system that can meet the emissions as provided by the EPA2007 standard; a generic system with all main components is shown in Figure 8-2. An exhaust system of these characteristics can only work using low-sulfur fuel (<50ppm sulfur content) and increases the cost of the system significantly. Because of this for developing markets that require low cost work trucks that use medium sulfur content fuels (50ppm- 500ppm sulfur) modifying the system is a must.
The project consisted in re-engineering an engine system that had been designed for the EPA2007 standard and prepare it to meet the EPA 2004 regulation for a market that used medium sulfur fuel. Complex engineering problems of this sort are seldom tackled by a single company, but it is rather a joint effort of the engine supplier, exhaust supplier, third party engineering sources and the OEM that collaborate to get the problem solved. In this case all these four parties were present, and getting to an economically feasible solution became a major issue. The following three are the main
146

problems we encountered in arriving to a solution: technical knowledge, team coordination and risk management.
PROBLEM 1: Technical knowledge
Solution of complex technical issues requires team work and a common understanding of the task at hand. In many cases, team members with different technical backgrounds will have different interpretations of what the problem at hand is and this will make finding a solution an almost impossible task. For the situation described above, it was observed that we did not all have the same amount of technical background in regards to diesel engines and their emissions. It initially took the team around four months to level the knowledge field and begin constructive discussion; prior to this point most of the conversations were fruitless because it was as if each party was using a different language. A clear example of this was that each team member - OEM, suppliers, third party engineering - had different interpretations of the EPA 2007 standard, and what it would take to solve the problem. Getting to a consensus on this item took over a year, but getting there was the largest contributor to solving the problem.
The lack of technical knowledge, also led some team members to propose solutions that were in technically infeasible. Team dynamics regarding these infeasible solutions would follow patterns as described here. Members of the team that supported the idea would feel that the other parties were being unhelpful and did not really want to solve the problem; if there was already a solution that in their minds would work, why did the rest of the team not get it? At the same time, some of the opposing members, sometimes those with better technical backgrounds in the subject, would stop listening and become unresponsive to any request form those team members that were deemed less knowledgeable. As a result the team became fractured and meetings became unproductive. The infeasible ideas would clog the work agendas for weeks with little or no progress and prevent the generation of valuable new ideas. An aspect that heavily influenced this weird dynamic was the distance between different team members who for the most part communicate using phone conferences.
For the OEM it was necessary to have a team with third party engineering and suppliers in order to solve the technical issues in time for the vehicle launch. Initially the OEM team took the approach of only requesting status updates from these team members and avoided getting too involved with the technical details of the work others were performing. However, it was seen that as a result good management of the engineering resources was impossible, and that toward the end it was only through cooperation and joint resources that a solution was found. For the leaders of a multifunctional or multi party team, it is always easier to step back avoid the technical details; minimizing cost and improving the process however requires detailed technical knowledge for advancing.
From the difference in technical knowledge three main issues were derived.
- Requirements and standards were interpreted in different ways - Infeasible solutions and reduced cooperation
147

- Team management and cost optimization
The team eventually gained equilibrium in the knowledge they had, and were able to move forward and solve all the technical issues. Team work became much smoother and short, productive
meetings became possible.
PROBLEM 2: Team coordination
The team under consideration in this analysis came from three sources - OEM, supplier, third party engineering - and was also located in two different countries and three cities, all more that one hour flight in distance. As a consequence the team rarely met in person and most conversations were conducted over the phone. In addition, the program had do sort through a myriad of legal aspects and dealt with an ever changing core team. These characteristics, in addition to the knowledge discrepancies that have already been explained, made effective management of the program and effort coordination almost impossible for the first half of the project.
Lack of team coordination negatively impacted the team in many ways. The following list summarizes a few of them:
- Diminished credibility with upper management - Reduced team motivation - Slow progress towards issue resolution - Engineering rework - Unproductive meetings - It was Impossible to sign a joint work agreement
All of these problems that derived form the central problem of coordinating the team were in great part related to the lack of personal interaction among the team members. This lack of interaction made relationships difficult and understanding the other parties' vantage points unattainable. Of the issues listed, it was probably the difficulty to sign a work agreement that was the best indicator of bad coordination. To sign the agreement all parties needed to understand the problem, trust their counterparts and agree on a work plan. Signing the joint work agreement happened around the same time that technical knowledge matured and the team came to a single understanding of the issue.
Solving the problem was done primarily by enabling face to face communication and providing opportunities for hands on work. Extensive use of a liaison engineer on behalf of the OEM also improved coordination efforts significantly, as there was a person in the team that could understand the needs of both and then help make the translation. Last, but important to the coordination, was the cultivation of an element of trust amongst the participating parties that allowed each to take come additional risk and resulted in being able to sign a work agreement that was beneficial to all.
148

PROBLEM 3: Risk management
Product development projects can be seen as exercises in risk management; adequate risk management requires technical knowledge. In the project there was some doubt with respect to the feasibility of meeting the EPA2004 emissions by using the new engine and performing minor tweaks. In particular, the suppliers did not want to commit to signing an engineering agreement that would commit them to deliver an engine that met the emissions standard with out needing major hardware changes. On the other side, the OEM wanted to make sure that the supplier would do everything and anything to have the engines in production, and therefore would send requests for quote that included broad statements such as "supplier will ensure that engine shall comply with all relevant emissions standards". By using this approach the OEM passed on almost all development risk to the supplier, and as a consequence the supplier would return engineering estimates that covered the development of anything and everything that could go wrong. This situation was largely the result of a lack of knowledge on behalf of the OEM team, as to what the actual capabilities of the engine hardware were.
Although the model of using full service suppliers has been used within the automotive industry for some time, it has been proven that it is in the detail of using this resource that true efficiency lies. Giving the full responsibility for system success to a supplier can be done on many levels, and the exact nature of the agreed upon interaction can either reduce or increase the overall project cost. In the case of the engine development, giving the full responsibility of delivering an EPA2004 compliant engine to the supplier meant that all the project risk fell in their hands. Managing the relationship in this way drove the overall engineering project cost up by a factor of ten; this makes sense when the supplier is left no way out of the agreement other than almost making a new engine to meet the requirements.
Careful partition of the responsibilities that each team member would have, and shared responsibility for delivering the program, quickly drove the cost down and allowed the program to become a reality. An element that must not be dismissed here is that achieving the optimal balance between the teams took the joint work of engineers and buyers, not just buyers as was the case initially. Risk management made this program a reality, but the delicate nature of this item was seen in a similar project that was cancelled, because of high costs that we assume came from inadequate risk management.
INSIGHTS
From this one example in product development we have shown three main problems that made it difficult to execute and their related sub-issues. The following are five generic lessons from this project that can be applied in future projects.
- Know the technical system at hand, evaluate the risk involved in the development of the system and the parcel the risk in the most cost effective manner
* Do not pretend that by creating a black box and telling someone to solve the problem it will get fixed in an economically feasible manner
149

- Demand that engineers work with their supplier (engineering counterparts), and have detailed knowledge of their costs and negotiated agreements.
* Have engineers work with purchasing to insure that risk is managed optimally Ensure that all team members have a common understanding of problem
* Seek a common language (this can be a good graph, an ESOW (engineering statement of work) or some other team defined manner, but everyone must understand the problem
- Always use liaisons in complex technical issues as bridges for information * Make sure that the 'home' team recognizes who the liaison is, and that there is fully
transparent communication - Optimize for overall project cost
* Manage the risk incurred as a tool to reduce development costs
We can take these lessons and look at the product development system. The product development system should make sure that teams participating in technical problems get acquainted with the details of the project as fast as possible. Also, the teams should seek to define a common understanding of the problem and direct this towards finding the solutions that best balance cost, time and performance.
In the actual project discussed here, heated debates were necessary to come to a common agreement, and it took months before progress could be made. However, once the elements described above were in place the project came to closure on time and below budget.
PROBLEM SOLUTION AND PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
Technical excellence is one of the drivers for executing excellent products, and the PDS must work to drive people to become technically excellent. In this example we worked to ensure that all members of the team grew together through the development process and acquired incremental technical knowledge to allow the generation of a solution to the issue. It was done by means of generating detailed technical reports that explained the nuts and bolts of the system to as much detail as was possible.
Interpretation of design standards, units and requirements is a conversation that must happen within team. Failure to do so causes some of the most sever engineering mistakes; for example the crash onto the Martian surface of Nasa's Climate Orbiter in 1999. Work in this team was done to arrive at a graphical representation of the problem and separate the issues to allow for work on each.
When possible always take coordination between engineering groups as close to the engineer as possible. In the diesel team the dynamics were established to allow direct resolution of engineering issues between engineers avoiding hierarchical escalation through the ranks. Some of this was due to the increase understanding of the technical items on behalf of the engineering team.
150

Team coordination using work plans that are created backed by face to face interactions aid the
communications process throughout the development. For this team we made significant efforts to
provide for forums of face to face discussion to create trust between participating team members
and I served as liaison to ensure that all technical communication was tended to as best possible
and the team maintained focus.
A PDS that can mange the risk associated with product development with efficiency, is one that has
confidence in its capabilities and knows its strengths and weaknesses with sufficient detail to know
how to best interact with suppliers, validation procedures and design elements. Use of this resource has the potential to reduce cost and time by at least three times.
8.6 System to Component Interfaces - A/C System Development
SITUATION DESCRIPTION
Development of A/C (air conditioning) systems for automobiles is not a trivial matter. As a system, the A/C requires interaction with many vehicle systems - the engine as an energy source, with the
body for support, with the vehicles interior ambience to distribute cool air, with the instrument
panel for support and with the vehicles cooling system for heat exchange. In aggregate, the A/C
system is a complex vehicle sub-system and one that has many individual components. The
performance of each component has an effect on the overall system and clear knowledge of the role of each component can help improve the system performance.
In one particular development vehicle freshening the complete A/C system had been chosen to stay with out any changes for the new model. The whole vehicle would be changed by updating the
exterior, interiors, a new transmission and an engine with minor changes. Therefore, no budget was allocated to improving the A/C system and for the most part it was not even considered. Upon building the first prototypes, the vehicle exhibited an unusual moaning sound when the A/C was turned on; the issue quickly grabbed the top spot in program issues and significant amounts of engineering and development were put into solving the problem.
This whole situation was eventually solved but several interesting problems came up along the way.
1. System and component interactions 2. System and sub-system development responsibilities 3. Leadership
Most of these issues relate to the A/C system interaction with the vehicle and the inherent difficulty that exists in finding the cause when it had been assumed that there would be no problems to solve.
s Within the automotive industry, updates to a vehicles esthetic with out major structural changes is called a 'freshening'. These updates normally happen 3-4 years after initial vehicle launch.
151

PROBLEM 1: System and component interactions
The problem with the A/C system appeared later than expected in the development program and
was a general surprise to all of us on the team. Initial evaluation determined that all vehicle
combinations were affected, and this initial assumption caused problems for many weeks. It
afterwards became clear that there were in reality several different issues, and that the main factors
that needed to be established were the following.
- Engine operating regime (idle or off-idle) - Engine type (V6 or 14) - Transmission (manual or automatic)
Separating and providing granularity to the problem made making improvement to the system possible and clear to all. However, initial confusion regarding what the problem was and who was
affected caused about 2-3 weeks of engineering and testing to be less effective that it could have been.
In addition to this, it was seen that there was very little clarity on how the interfaces between the
A/C system and other vehicle components would be designed. To some degree the interface definition was not as good as expected or needed once detailed problem analysis begun. As a consequence, each and every interface was tested for changes between the prior model (no problems) and the new 'moaning' vehicle.
Understanding of how the A/C system related to the rest of the vehicle was unclear; however, careful analysis of the changes that had taken place with the rest of the vehicle did point out a need to have included the development of a modified A/C system within the program. This lack of system- to-subsystem interactions within the A/C itself, made finding a way to improve the performance of the vehicle a task of trial and error that was partially led by an experienced A/C system engineer. Few if any documents on how to resolve common A/C systems problems or diagnose issues were available, and probably made the team work far more than needed.
PROBLEM 2: System and sub-system development responsibilities
Half of the work to solve the A/C moan issues came from trying to make the owners of the vehicle attributes work with the owners of the A/C system. It was not initially clear how the work should be parceled or conducted, and neither was this clear after the problem had been solved; but it could not have been resolved by any of them separately.
Responsibility to deliver a vehicle with an A/C system that works without fault must be undertaken by all team members. In the development of the A/C system there was a fight to try and avoid as much of the system performance responsibility as possible; this problem is seen often and is driven by the scarce nature of resources. Getting the teams to work together required a group understanding of what the problems was and what the joint plan to succeed would be. Within this
152

plan there was also definition of the role that each person would play, but overall it was the team
that needed to deliver.
Much of what these teams needed to interact correctly was guided by how the vehicle and the A/C
system were architected and identifying the points where boundaries crossed. For some systems, the architecture and interfaces have been defined in great detail, while for for others, this is still a
work in progress, but teams that are confronted with system level problems must achieve some
understanding of the system architecture.
PROBLEM 3: Leadership
Leadership has been described in many ways but for many leaders, one of their main tasks is
removing barriers that impede work from getting done. This project highlighted that it is not always clear what the barriers are, and that for leaders what may not seem like a barrier can constitute
major issues for others.
In working to develop the A/C system, testing parts and bringing vehicles back and forth were
everyday tasks. These tasks seem straightforward, yet were some of the biggest inhibitors for
getting the work done for the team. For many team members, these tasks presented major issues, and delays of almost a week could be traced to not having a car on which to work or other similar matters. In this example, the ability to help the team with these minor issues and providing some cadence to the work helped every member work at their best. Keeping the team clear to work is also part of the leadership role. The team needs to be able to focus on the work at hand and have a
single line of direction; spending several hours a day trying to explain to every team member what the next steps are goes no where. Most of the time, experienced engineers will know exactly how to solve a problem once the scenario has been adequately characterized.
For the A/C system, the variety of specialties that came to confluence to solve the problem, and the
high profile of the issue made conflicting direction the rule. The unexpected nature of the problem also meant that resources and people to solve the problem were scarce. Here, leading by listening carefully to each of the experts for different subsystems to gain technical insight, solving the little- big issues and providing one direction to the team drove issue closure.
INSIGHTS
From this example we have taken the following lessons.
- Capture knowledge on system development in an orderly fashion for future reference - Identify system interactions and use them to lead issue resolution - Use a rigorous systems approach to understand the implications of changes throughout a
system - Drive team accountability - As a system designer, make the interfaces a part of your domain - Lead the vehicle by knowing details
153

- Remove the little-big problems
The A/C moan issue was resolved in record time as compared to other similar issues that arose at a
similar point in time. Commitment to solving the problem and spending time to working as a team
became invaluable. Team dynamics driven by the approaches described worked incredibly well and
led to generalized feeling from members that working together again would be a good time.
PROBLEM SOLUTION AND PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
Definition of problems and leadership of complex engineering issues requires that we develop people with the right technical capabilities and that leadership create trust amongst participants to elicit from hem the solutions to technical problems.
Documentation of what we learn and contextualization of or knowledge make the difference between solving the problem for this time, and getting the problem out of the system for good.
In this example there was a clear issue in the understanding of different levels of detail within the
system. The PDS should arrive at solutions that crack the code of systems and provide next generations of engineers with clarity as to what should be done. Every effort should be made to make knowledge available to all members of the product development community.
8.7 Knowledge Linking and Innovation - Fuel Economy Improvements
SITUATION DESCRIPTION
Fuel economy is a controversial subject and although almost people would agree that improved fuel economy is good, this opinion only holds if vehicle performance, comfort and size are maintained more or less unchanged. In addition to developing new technologies, lowering weight with better materials and reducing power losses through improved components, fuel economy is gained by balancing overall vehicle performance and other attributes to obtain a combination that is attractive to customers.
The improvement of fuel economy is critical to all automakers today, and the work done to get better miles per gallon is a good example of when teams getting into tight spots and being unable to innovate. In this example, the team was lagging behind in meeting its fuel economy numbers, and as a result had begun pursuing many different strategies to improve. A few months of work resulted in little progress and no consensus from all the team members as to what the next steps were - the path was still unclear. Two problems were seen to be the cause for this:
1. Prioritization of work 2. Joint problem solving
154

PROBLEM 1: Prioritization of work
Getting improved fuel economy is a tough technical problem, but it is also an opportunity for generating competitive advantage. Getting everyone on a vehicle team to buy into what the true brick walls to improving fuel economy are is not a trivial process. In the development example there were many different aspects of the vehicle that could all contribute to improving fuel economy, but the team was not focused and little actual progress was being made.
The team did not have a unified method to visualize what the major contributors to poor fuel economy were and as a result found it easy to wait and see if the extra work was actually needed. For many of the vehicle team members, it was customary to believe that if they waited long enough someone else would solve the problem and the issue resolution continued to get moved back. This was due to the nature of fuel economy, where pinpointing one culprit is often very difficult.
Getting buy in from the team to the direction was also difficult as all directions required additional work for which budget and people were not always available. Lack of prioritization drove the available resources to be used across the board and reduced their effectiveness.
PROBLEM 2: Joint problem solving
One of the aspects of the engine that was found to be an area of opportunity was the management of engine idle speed; the lower the minimum idle speed the less fuel the vehicle would consume. The minimum engine speed is determined from many factors that range from engine stability to vehicle shake. In this particular case it was found that it was oil pressure that detracted the team from lowering the engine speed any more.
Partial solutions to enabling the engine to run safely at lower idle speeds were available within the overall team; conversation between these parties had not occurred. The problem could not get solved for some time due to the difficulty of linking capabilities from different sides of the organization to attack a common problem. Observation of the situation reveled that the team had never really talked because each of the technical areas worked at different phases within development, and had therefore never shared a common forum for conversation.
INSIGHTS
Generating conversation in teams seems a straightforward move, but getting people to ask the right questions and propose constructive ideas in those conversations is very difficult. One way of making these conversations happen is by providing the team with common objectives and creating short term discussion forums that aid communication; participation of management in these discussions can aid issue resolution as long as there is trust between team members and their managment. In addition, the teams in the example had difficulty meeting in person due to their location and had therefore never looked at the problem while in the same room. In come cases a single person that can go and talk to all team members in person will be enough and avoid having to move everyone to different locations.
155

Accountability for delivering on issues with shared attributes should be assigned to teams and never
to single elements of the organization. If the problem changes and new members are added, the responsibility remains with the team and new members become part of it as well.
Forcing teams to deliver solutions in short periods of time can sometime motivate the necessary conversations. If timing is short enough that a day without agreement will mean team failure there will be increased incentive to meet.
PROBLEM SOLUTION AND PRODUCT DEVELOPMENT SYSTEM DESIGN CONSIDERATIONS
In both of these problems effective solutions were driven by increasing my direct communication with all team members and gathering them all in shared forums to discuss our joint issues.
Innovation for reducing engine RPMs was accomplished by viewing the problem from a system perspective and helping the team look at the problem in this manner as well. The number of ideas generated by the team outnumbered those that we could try, but a quick selection based on implementation times and costs quickly made it clear which ones were feasible. The PDS must encourage communication between different disciplines and drive for solutions that are optimized for the full system.
Delivery of team goals is never trivial, yet in setting were accountability is unclear because of technical complexity teams must become accountable as full units to enable them to find balance. The PDS goals must balance individual and team delivery with care.
8.8 Key Takeaways - Case Studies in Automotive Product Development
The examples presented provide an overview of common problems that engineering organizations have and that the product development system should strive to design out. To summarize these lessons and prepare them for use in our application of the product development system architecture, the following is a list [Table 8-2] of the main architectural lessons that these examples have revealed.
A critical item to note from looking at each of these examples is that in absolutely every case, the detailed knowledge to carry out the task at hand and solve the problem was available. This however did not help solve the problem; therefore the experience in solving these issues points towards indicating that larger system issues were the culprits for the systems failure.
For each further explanation of the product development system considerations and the architectural decisions that this drives are presented in chapter nine.
156

System Design Considerations (Architectural Lessons) Major area of impact
(product, process, people, tools, goals)
Example case
Align process timings between supporting teams with care to enable Process, People 8.1 1 synergies
Ensure that derivative teams are represented and known within the People, Process 8.1 2 adequate forums of the base program
Knowledge between team members must be similar to allow People, Tools, Goals 8.5 3 communication and issue resolution 4 Use risk management to reduce overall project cost Product, People 8.5 5 Use liaisons to unite geographically distant team People 8.5
integrate suppliers to the engineering work flow and understand their Product, People, Process 8.5 6 needs and capabilities
Effective supplier managements required detailed knowledge of the Product, People, Process 8.5 7 technical system being designed Goals 8 Good engineers, are not always good communicators People Gral.
Develop trust within the team to ensure the right solution space is People Gral. 9 explored
Promote the use of standard names for engineering problems, create People, Process Gral. 10 names as needed to achieve granularity 11 Revise the system architecture as part of the solution space Product, Process Gral. 12 Solve the big-little problems to enable teams to work People 8.6
Challenge assumptions and ensure that engineers are continuously Process, People 8.3 13 challenging them as well 14 Use liquid role definitions to improve work load balancing People, Goals Gral.
Begin looking at engineering concept definition by looking at the end Process Gral. 15 goal - production
Apply tools to the correct setting and avoid designing organizations Tools 8.2 16 around them 17 Use corporate tools as a way to achieve alignment People, Tools 8.2 18 Develop tools for labor intensive non value added tasks Tools 8.2
Know the limitations of virtual tools and exploit them as much as they Tools 8.4 19 let you 20 Use physical prototypes to achieve detail and large scale interactions Process, Product, Tools 8.4 21 Develop systems engineering capability People, Process Gral. 22 Interfaces are part of the design domain Product, Process, Product 8.6
Develop rigors methods to understanding change cascade throughout Product, Process, People 8.6 23 a system 24 Use accountability to drive innovation People, Process, Tools 8.7 25 Create forums to work in teams Product, Process, People 8.7 26 Locate teams close to each other to enhance communication People Gral.
People, Process, People, Gral. 27 Communicate to solve problems Tools
Table 8-2 Summary of system design considerations for designing the product development system
157

9 Design of a Product Development System
The goal of this thesis is to improve product development by designing a product development system. The entire problem is larger than the scope of a single thesis and therefore this thesis focuses on creating a framework for the problem with the intent of enabling further detailed design work to improve the FoM product development organization. This framework is developed by designing the architecture for the Product Development System (PDS). The architecture stands on the research presented in previous chapters, integrating academic and industry knowledge.
Product development requires all elements to work in synchrony for improvement. Having good people, processes, the latest CAD tools or great product ideas are not enough on their own. We talk about a product development system to convey this concept of a multi-element activity. Our improvement to the PDS is therefore dependant on our understanding of the multiple elements and interactions that take place continually.
The proposal for the product development system is one of integration of all elements in optimum balance. Different opinions as to how this may be achieved have been presented by other authors, some focusing on definition of the process, a few on how tools change performance and others on how the organization must be set up and communicate. After reviewing the work of many researchers in product development, one common element is the focus on adding value for the customer at every step. We will take a holistic approach to product development and make certain to drive our decisions based on increasing customer value.
Value in our case is the perception the customer has of how much benefit a vehicle provides for a given cost. This relationship is affected by the customers' expectations, which will dictate their satisfaction with our work. Product development plays a vital role in delivering value to customers, and has responsibility for at least two, and sometime three, out of five steps central to delivering value during the development of a new product. These five steps are:
1. Market and need selection 2. Definition of architecture 3. Detailed design and development (execution of the product architecture) 4. Production (final assembly) 5. Sale
These five steps represent major transition points in the value chain. At each point there is a major transformation of the form that the customer need takes. Adding value to our customer depends in part on our ability to perform these transformations with speed and quality. A summary of these steps and the associated transformation is illustrated in Figure 9-1.
158

Market Inforrat on
--------------
Market Need
Architecture -?definition
Figure 9-1 Value creation step and transformations at each interface
The best product development organizations excel at going from market needs to finished designs.
The architecture of the PDS must deliver a framework to enable the organization to accomplish
these transformations in the most effective manner possible. Not all organizations are equal, and to
deliver a framework that is effective the architecture must be specific. The product development
organization of FoM (Ford of Mexico) has been selected as the example, and will be used to create the PDS architecture.
9.1 Rational for Creating a New Product Development System Architecture
The product development activity is immensely complex and subject to continual pressure to improve because of its key role as a source of competitive advantage for companies. Chapter eight
presents a selection of problems from the automotive industry that highlights a variety of issues that
arise in product development. Additional research has surfaced areas of opportunity and much
advice on how to create better at product development organizations, yet there is confusion when
trying to select which improvement ideas to use and how to implement the selected improvements. We have therefore identified four generic problems that cause these confusions and present them
in the opposite page.
159
Lsa~a
WflrJE3I~i* mn0

Problem 1 - Technical complexity and multifunctional nature of product development
Product development is complex because of the combination technical and people issues. Each organization and product has unique aspects and this makes generating a single approach very difficult. We therefore find advice that is either too specific or too broad to be useful. Our approach must therefore be integrative and include the technical and people nuances of the FoM organization.
Problem 2 - Diverse nature of the technical problems in product development
Chapter nine the presents some of the problems that the PDO deals with every day showing how they vary immensely in scope, technical content, root cause, priority, duration, etc. There is no one single set of solutions that if implemented would cover all current and future problems a product development organization encounters. The architecture and the design of the PDS must therefore guide the resolution of problems of many technical backgrounds and evolve to meet future needs.
Problem 3 - Information available for improvement of PD is not all compatible
Chapters five through eight review in detail different aspects and elements of product development and present some of the characteristics that have been found to be important to successful product development organizations and their respective PDS. Looking at the variety of options and diverging opinion of authors, selecting a single option is almost impossible. Generating coherence amongst them proves to be difficult without a clear structure underlying the decision criteria and process. Our architecture for the PDS must therefore generate a single overarching framework to bridge the information available and the problems it solves.
Problem 4 - Implementation of improvement actions to product development
Implementation of improvement actions brought from outside to PDOs has proven to be highly ineffective. Proof of this is that even with detailed information about the Toyota PDS available to all, and the immense hype and acclaim surrounding Toyota's system, the number of companies that have successfully integrated Toyota's strengths and practices with their own is surprisingly small. Therefore the PDS foundations must account for the unique aspects of FoM.
Development of an architecture for the PDS of FoM will address these issues. The problems discussed above provide rationale to support the creation of a PDS architecture that allows FoM to improve its PD activities. As a group, these problems present a good overview of why product development is difficult to get right and why it represents a competitive advantage to those who excel at it.
160

9.2 Guide to the Architecture and Design of Complex Systems
The process of designing a complex system follows a general path very similar to that presented in Figure 9-1, and to the four stages that have been reviewed throughout the thesis - define, design, validate, launch. In this section we will present the approach that we will use toward creating the architecture of the PDS. The basic steps towards delivering the architecture are illustrated in Figure 9-2:
Characteristics of the PDS customers stakeholders
i PDSGoalDesign objectives
-I PDS Architecture Figure 9-2 Steps toward architecting a complex system, modified from (Crawley, 2006)
The following sections of this chapter will go through these three stages and cover all elements necessary to create the PDS architecture for FoM. One of the main reasons to focus on the architecture is because we want to be able to define standard interfaces among the components of the system that allow us to continue the work of improving product development in the future. The complexity of the system does not allow us to define in detail each of the possible interfaces in the system; therefore key characteristics of each of the elements aid us in creating cohesion.
9.2.1 Architecture of Complex Systems
Architecture is an essential attribute of all systems. Whether we know about the architecture explicitly or not, a great part of how a system delivers its functions is determined by its architecture. Architecture, for purposes of general systems design, has received many different definitions. The two following have been selected as some of the better examples.
* Architecture is the embodiment of concept, and the allocation of physical/informational function to elements of form, and definition of interfaces among the elements and with the surrounding context. (Crawley, 2006)
* Architecture is the value proposition, as established by the cost to performance relationship, that structure and character provide a product or entity. (Aguirre Esponda, 2008)
From these definitions we will say the following. For the most part, form and function (E. Crawley) are similar to the definition of the structure (G. Aguirre) of a system. Character (G. Aguirre) can be said to be a equivalent of the concept (E. Crawley). Both elements - the structure (form and
161
j
L- Ga
ramework

function) and concept (character) - fulfill different functions in an architecture and both must be defined.
The character (or concept) can be especially difficult to grasp and we therefore present the following example. As human beings, the 'how', the character or concept, is always important in our mental models. This is very clear when we think about the difference between driving around in a Rolls Royce Drop Head Coupe or in a VW Bug. Both cars can achieve the same primary function, but how they do so is different. We know people in assign a value to this difference by simply looking at the price tags on each vehicle. Therefore in designing the product development system, we must make sure that how the organization develops products is well defined. It is our desire that the added value people perceive in FoM is as high as possible.
9.2.2 Character and Structure Elements of the Product Development System
Definition of the structure and character of the organization is necessary to design the architecture of the PDS. Many product development systems have been developed prior to this one and therefore research has been done to understand what elements of structure and character have been found critical in the past.
We have found that for the elements of structure an excellent job has already been done to identify the five basic systems that constitute all product development systems: process, product, people, tools and goals (Browning, Fricke, & Negele, 2006). These five elements have already been used previously in this thesis to present general academic research insight to each of them. To design our PDS architecture, in the following sections we will define with accuracy what characteristics we seek from each of these systems.
The elements of character come form the development of the concept for the PDS architecture. The selection of the most appropriate elements of character for the concept was helped by information from interviews and work with the organization of FoM. Insights from literature and interviews with experienced product development leaders have been paired with the required function of the system and lead to the selection of four elements. The four elements selected were: communication, flexibility, decision process and perfect execution.
The elements of character and structure must be defined in with care to enable the development of the PDS architecture. Some of this work has already been presented in previous chapters, and we will use the next sections to summarize key aspects for each. The architecture of the FoM Product Development System will be an aggregate of the concept for the system and guidelines for the elements of structure and elements of form.
162

9.3 Goal and Design Objectives of the Product Development System The goal of this thesis is to design a successful product development system for FoM. To accomplish this we have designed the architecture for the product development system that enables structured
organizational and process change for FoM.
The first step toward developing the architecture for the PDS is to define what the design goal for
the system will be. The following is the agreed design goal for FoM:
Design Goal for the Product Development System of FoM: To revolutionize the execution of Product Development at Ford of Mexico to become a world class
organization.
This goal is based on FoM's vision and the input from the leadership of FoM. With this goal, and the
theoretical and practical background that has been presented in the thesis, we can define a set of
system design requirements. The design requirements define what the product development system must deliver to avoid failure. By focusing on what should not fail versus trying to enumerate everything that should go right we can make sure that our architecture will accomplish its basic functions. This approach to architecture is supported by more than ten of the heuristics listed by
(Maier & Rechtin, 2002). The three selected design requirements are presented in the following table.
Vital Few Requirements for the Architecture of the PDS
# Requirement Rational
Develop products of high customer value that are Product development systems exist to develop new 1 products for companies and that failure to deliver this
basic requirement renders the PDS useless
Provide direction, coherence and structure to all the Responds to the insights from the examples presented in 2elements necessary for developing a product this thesis where an incoherent and unstructured PDS
was the root cause of many PD problems
Provide efficient solution to engineering product Inefficient problem solving has been identified in all the development problems product development examples to be key to a successful
product development Table 9-1 Vital design requirements for the architecture of the PDS
The vital few requirements for the architecture of the PDS give us a high level direction. Additional granularity in areas that the architecture must cover is then addressed by developing a list of design objectives. The design objectives are specific to the FoM organization and therefore can be referenced to the main stakeholder for each one (details regarding stakeholders and their relation to FoM can be found in section 10.4). Design objectives for the Product Development System are presented in Table 9-2.
163

# Design objective (The architecture for the PDS must eliminate the failure to...) Stakeholder 1 Understand customer needs FoM 2 Develop products that are manufacturable FoM 3 Accumulate and develop technical knowledge and expertise FoM 4 Allow for efficient and effective communication amongst all members FoM 5 Avoid the creation of silos FoM 6 Provide a structure for organizational learning (avoid repeating mistakes) FoM 7 Efficiently manage the risk in product development FoM 8 Efficiently manage requirements FoM 9 Adapt to changing market conditions and project types FoM 10 Enable robust and efficient validation of vehicles FoM 11 Deliver designs that can be assembled well the first time FoM 12 Maximize efficient usage of virtual design tools FoM 13 Provide organizational structure FoM 14 Allow for clear understanding of product FoM 15 Generate product innovation FoM 16 Foster technical and personal growth of people FoM 17 Develop new more efficient product development processes FoM-Global 18 Develop vehicles to meet global needs FoM-Global 19 Provide and improve work opportunities in Mexico FoM-Mexico 20 Comply with local regulation FoM-Mexico 21 Bring economic growth to the region FoM-Mexico 22 Attract more work to the organization FoM-NAC 23 Follow and comply with corporate NAC processes FoM-NAC 24 Provide intuitive organizational alignment to the NAC PDO FoM-NAC 25 Align suppliers with NAC engineering, manufacturing and purchasing FoM-NAC 26 Facilitate coordination of development efforts with global development teams FoM-NAC 27 Insure compliance with regulatory requirements on projects FoM-NAC 28 Deliver vehicle attribute support as required FoM-NAC 29 Generate a positive reputation FoM-NAC 30 Provide system, subsystem and part knowledge to all who require it FoM-NAC 31 Drive internal alignment of NAC and final customer FoM-NAC 32 Develop next generation standards, procedures, test and requirements FoM-NAC
Table 9-2 Design Objectives for the FoM PDS by stakeholder
The list of design objectives summarizes situations and requirements that the architecture for the PDS of FoM must address. For each of the design objectives the key stakeholders are identified to ensure that the needs of all stakeholders are taken into account.
Design goal, system requirements and design objectives define the full scope of what the PDS architecture must deliver. In addition to these, knowledge of the internal workings of the organization and the context of FoM must be known to develop the architecture.
164

9.4 Contextual Setting for the Product Development System
Context changes what the best architecture is for a given problem. The improvement of product
development for the FoM organization requires us to understand its context to develop the best
architecture possible for its PDS. The context of the FoM product development organization can be
summarized in the following description.
FoM PDO is a product development organization that is based in Mexico City, Mexico. It is an appendage of the larger product development organization of NAC. The work between NAC and FoM is envisioned to be 100% transparent in regards to processes, tools and standards, with FoM providing engineering and product development support as required by NAC. FoM has been building up its experience in product development, but is still a young organization. People external to the organization have described FoM as being extremely enthusiastic and to exceling at low cost product development.
e to change zed model tion s ze and 7
.Direction on work 0 ,peraL ng procedures
*Su [))li or base •GCeographicaI oca1tion *Low cost work force
'9.. .... . .
/Cosl pressures Cngineeri ng co mpetition
Culture nization size rage age of engin
Figure 9-3 Three levels of the specific system characteristics that are selected for definition of system requirements
The figure above [Figure 9-3] visually presents the different stakeholders for FoM and lists some of the key aspects of each. These stakeholders and their relationships to FoM define the context for
165

the FoM product development organization. A full list of the interactions that were registered is presented in Table 9-3.
FoM PDO
Description Relation
The organization size is between 200-400 engineers FoM
Average age of engineering group is < 35 years old FoM
10 years of success and experience in product development FoM
Small company organizational culture unique to FoM FoM
Understanding of resource scarcity and the importance of cost FoM
FoM Product Development is part of NAC's larger Global Product Development FoM-NAC Organization Development projects are of two types: local developments and export projects FoM-NAC Development facilities are limited in Mexico, FoM shares facilities around the world FoM-NAC
Standard reporting and project management tools from the corporation are known FoM-NAC FoM objectives are carried out using a balanced score card FoM-NAC Aggressive entry of low cost engineering sources such as China and India Global
Existence of a large engineering capacity within suppliers Global
Rising health care costs in the US Global-NAC
Increased regulatory pressure on safety and environmental requirements in the United Global-NAC States Need to integrate advanced technologies to meet tougher customer needs Global-NAC
Increasing fuel costs Global-NAC
Entrance of new low cost automakers from Asia Global-NAC
Low facility investment in engineering facilities Global-NAC-FoM
Neighbor with the United States Mexico Time zones +/- 1hr to the United State, Brazil and Argentina Mexico
NAFTA free trade agreement with the United States and Canada Mexico
Forty three free trade agreements with countryies around the world Mexico
Low cost work force of both qualified blue collar workers and well educated white collar Mexico workers Cultural similitude to the United States Mexico
Widespread knowledge of English amongst professionals in Mexico Mexico Government regulatory incentives to pursue development of engineering and Mexico manufacturing Highly innovative Mexican culture imbedded in most Mexican engineers' thinking Mexico-FoM
Large installed supplier automotive base, over one thousand operating in 2006 Mexico-NAC-FoM
Corporate culture NAC Resistance to change in the product development model, from a centralized to a global NAC model
Table 9 3 Contextual aspects of the FoM PDO for the design of a PDS
166

9.5 Concept for the Product Development System
The concept in a system describes how it delivers its function and adds value. The role of the concept in a system's architecture is critical as it maps form to function and informs us how the system will perform it's functions. Defining the concept requires us to understand what the expected functions from the system are, the context in which it will operate and knowledge of the inner-workings of the system. All these elements have been reviewed to this point and allow us to define a concept for the PDS of FoM.
The following elements have been brought together to define the concept for the PDS:
* Function - The design goal, system requirements and design objectives summarize what the function of the system needs to be.
* Context - Summarized in section 10.4, and understood in detail through direct work with FoM.
* Knowledge of the system - product development organizations and their work have been studied in detail in chapters 5-9 of this thesis.
Knowledge of product development helped identify what the elements of form available to the system are. Products, people, process, tools and goals were selected as the five elements of form in product development systems and enabled us to map function to form. Figure 9-4 presents the mapping between function and form for the FoM PDS and the main elements of the concept.
-K I IS17
t :E 4
Figure 9-4 Concept for the PDS, mapping the systems function to form
167
[.4

The system requirements and design objectives need to be met by the elements of form that make up the system. The concept allows these two worlds to interact and is intended to provide clarity about how the system works. The concept for the system is the following:
Concept for the Product Development System of Ford of Mexico
To create an uninterrupted flow of information from customer needs to finished design by mastering excellent communication, flexibility to adapt to changing requirements, robust engineering decisions and perfect execution of all activities.
The concept described focuses on the need of product development to deliver finished designs that meet customer expectations. Furthermore it gives details of the character elements that the organization must poses to achieve its purpose. The uninterrupted flow of information sets a stage for removing the barriers that avoid better product development and ensuring that we deliver on what the customer requires.
The following two sections present the detail for each of the elements of form and character, leading to the architecture of the system in section 10.8.
9.6 Character Elements of the Product Development System
The character elements of a system are critical as they define the systems concept. The character elements represent how we want the system to work and deliver its function. The elements of character selected to become part of the PDS architecture were found by analyzing the cases presented in chapter eight, conversations with FoM leaders and knowledge from external PD groups. The subset of four elements that were chosen is summarized in Figure 9-5.
* e c g n
* Inoato
* 0 ExelnenSrhtc:iempe etto
L* 9,g
u~tyadcneti etpout
Figure 9-5 Character dimensions for the product development system
168

The elements of character are key part of the product development system, but making them part of the organization requires continual effort. We hypothesize that with time character elements and the concept of the PDS become the organizations culture. This thesis has proposed that culture is a characteristic of organizations that can be developed and designed. The four elements of character are key guidelines toward what we want the culture of FoM to be. To define how each character element builds toward the PDS architecture the following sub-sections provide guidelines and examples for each element.
9.6.1 Excellence in Communication
Communication has been demonstrated to be essential to the product development process, and has effects on both internal operations and the ability of the PDO to communicate towards the outside. External communication is essential for FoM because it will allow interaction with NAC's product development offices around the world. Efficient and effective communication amongst the PDOs of NAC is the only way to benefit from global large-scale engineering operations. Equally important is the internal communication, which for example will enable FoM to innovate and solve problems by allowing their constituents to share ideas and arrive at solutions that benefit all.
Excellence in communication is an element of character in the architecture of the PDS of FoM. Every example in chapter eight and all engineering problems (of success and failure) that have been analyzed to for the thesis find communication as an element of the utmost importance for product development. Figure 9-6 summarizes what excellence in communication means for the product development system we are designing for FoM.
Communication happens both the internally and the externally. The effectiveness of FoM in communicating will be a function of both. The following are the key aspects of communication in both forums.
1. External forum - Excellence in communication external to the organization makes the PDS relevant, useful and transparent to other engineering organizations
2. Internal forum - Excellence in communication is critical to the information transformation process of product development and necessary to improve the performance of the PDS
Excellence in communication, as we have defined here, must be reflected in each and every aspect of the Product Development System. Achieving excellence in communication will help the team solve new problems and create opportunities to innovate. Communication supports the three vital requirements of the PDS - customer value (innovation), coherence (coordination), solving problems (information) - and is because of this is a key to differentiating the PDS, and the organization that implements it.
169

Use standard communication procedures for coordinating and informing (location, content, source and purpose) Locate product teams in close proximity to increase innovation and increase performance of the PDO Use written means for communicating decisions
Select the highest bandwidth communication media that is economically feasible for communicating (faceto face -> phone -> email) Develop excellent long distance communication abilities (phone conferencing, video conferencing, net-meeting and email)
9.1 &9.2 - shows how poor communication caused process, timing and cost issues for the program All Other Examples- Poor communication was a culprit of poor team performance in all examples that have been presented in chapter nine and in all of those analyzed in conducting the research for this thesis
Figure 9-6 Character Element: Excellence in Communication
9.6.2 Flexible Capabilities
Product development is dynamic in nature, and the problems that are presented are seldom the same twice. Workloads throughout the development of a product change daily in their intensity and the need for specialists in different areas evolves continually. Technical knowledge flows in directions not conceived before and new expertise is needed more than ever. Definition of an organization's exact role in a global framework changes with the winds of economic pressures, exchange rates, politics and many other factors out of our control. Innovating creates work of kinds we did not imagine before and creativity requires us to work in areas that can create uncertainty and discomfort.
These are the realities of FoM and the product development system, an environment of change and great uncertainty. The ability of FoM to adapt to changing circumstances, yet be efficient at the tasks it must do a thousand times, is a balance that is challenging to achieve. Flexibility of the product development system's capabilities is therefore crucial to surviving in today's product development environment. What we seek to achieve in a system that can cope with these changes is to generate flexibility within a structure (Tatikonda & Rosenthal, 2000). Flexible capabilities are amongst the four selected as character because of the realities of the environment and because in recent history FoM PDO's flexibility has been one of the most valuable qualities identified.
170

Flexibility becomes a critical issue for FoM because of its small size and intense focus on low costs.
Normally, in larger groups there is room to have people specialize in one or two tasks and the amount of work for each technical specialty will be enough to keep most of the resources in use. However, for FoM this may not be possible and we must continually work at close to full capacity utilization. If FoM PDO seeks to become the premier low cost option for NAC it is not acceptable to have rigid specialists; it is necessary to have flexible specialists. One important enabler for this flexible specialist is the natural disposition of Mexican people toward creativity and ease of adaptability.
Flxil Capablitie
E'S 0 6' I Adpablt tocagn6rjcsadrqie e
Maintain structural flexibility to allow quick team set up for new projects
Use process standardization to increase and enable flexibility
Keep the organization close to full capacity utilization, and use flexibility to grow organically at low cost Develop flexible engineers by seeking well balanced depth and breadth
Develop a methodology to enable continual improvement through systemic process improvements Leverage individual flexibility to foster a liquid organization
9.4- Individual flexibility of role and responsibility
9.5- Flexibility of technical competence
I FoM's track record - recent past projects demonstrate need for flexibility at the system level in resource allocation and project scope
Figure 9-7 Character Element: Flexible Capabilities
FoM PDO must create flexibility at all levels. The system must have built in traits that allow for rapid changes, and, at the same time, the individuals, specific tools, processes, and methods must be such that they all embrace flexibility. In particular, FoM PDO must create flexibility at the individual engineer aligning everyone with the notion that their work is dynamic, and that they are valued by their ability to achieve balanced depth and breadth. The employees of FoM will be expected to take on new tasks without a flinch and support the delivery of team objectives in areas, even if it mans working in areas that are not of their immediate specialty. Such behaviors at the individual level will enable the system to achieve true flexibility.
171
I

Three areas of the system have been selected to provide flexibility to the PDS and respond to the
changes in environment as previously explained.
* Resource allocation - refers to our ability to move resources from one project to another * Technical competence - refers to the ability to embrace new knowledge, learn and accept
challenges * Project scope - refers to the ability to take on projects of varying sizes and complexities
For FoM these traits have been second nature for a long time because of the size of the
organization. However, transitioning toward a larger more complex organization will require FoM to have these three system flexibility traits to deal with the future challenges. For the FoM PDO developing flexibility will allow them to keep abreast of possible changes in their work description. We will call the PDO flexibility that emanates from the individual the liquid organization (Perez Oyamburu, 2007).
All of the three vital requirements for the system are covered, by using flexibility. In particular, flexibility allows us to provide direction and coherence to the product development elements while we optimize the efficiency of FoM PDO operations. Having flexibility in the system will allow FoM to approach the optimum, without completely unbalancing the organization. Therefore flexibility is a useful character element for the product development system; one that can help ensure that our PDS design can adapt to changing conditions.
9.6.3 Nimble and Robust Decision Process
At every point during the development process, the product development team is making decisions with regard to an infinite number of choices available. Beginning with the simpler part-level decisions like using three or four bolts to attach a part, and extending to system level decisions such as defining the system goals, product development is driven by multiple series of related decisions. The performance of FoM PDO in terms of quality, cost and schedule is therefore greatly affected by how these decisions are made and which alternatives are chosen. A quick example of the importance of decisions can be seen in the paper by Charles Fine and Daniel Whitney (Fine & Whitney, 1996) where they discuss the 'make-buy' decision that product development organizations frequently face.
We have selected the decision process as an element of character because in all product development examples presented that took place in large organizations, going through multiple approval stages and getting decisions made for the program took as long as the related engineering activities. At FoM analysis of one of the largest and most successful recent product development projects (the development of an A/T variant of the regions best selling car) showed that one of the main differentiators that had been their ability to make quick high quality decisions for emerging product development problems.
172

Align the decision process to avoid asymmetries
Use a rational data driven decision process at all levels of the organization
Define what decisions have multi-functional / system implications and enforce formal design reviews for these Make engineering decisions at the lowest level possible - empower the individual engineers Have well defined decision forums and hierarchy
9.3- clarity in decision process reduces engineering work
9.7- undefined decisions process and responsibility makes developing attributes almost impossible FoM PDO experience- analysis of additional product development examples with FoM management identified the decision process as key to efficient product development
Figure 9-8 Character Element: Nimble and Robust Decision Process
Decisions are frequently made without sufficient bases or are postponed unnecessarily (Fricke, Gebhard, Negele, & Igenbergs, 2000). Both of these outcomes, based on an extensive study of flexibility and discipline in product development, can be related to the robustness of a decision and how fast we can take it. Ideally, we could hope to take perfect decisions, instantaneously; however, in reality, these two aspects must frequently be traded off. The speed and the quality of a decision are attributes that are associated with single decisions or can be assigned to small groups of decisions. However, for the full set of decisions taken by the product development system in order to deliver a new product, we have chosen to use the following two characteristics.
* Nimble - relates to the speed for making decisions at the system level * Robust - relates to the quality of our decision process
For the PDS of FoM the terms - nimble and robust - have been selected to describe the full essence of what making decisions means. For the PDS we are designing, nimble decisions mean the PDO's ability to navigate the various approval steps efficiently, while minimizing unnecessary considerations and delays. It also conveys our intention of having a decision process that can take on non-standard decisions and quickly incorporate them into the system. For FoM the nimble decision process will minimize the time it takes to make decisions at all levels.
173

Robust decision process is characterized by the consistent high quality of decisions that are made. Within the PDS high quality decisions require awareness of the decision process within the system. FoM must therefore make sure that all the people that need to participate in the decision are accounted for and that they have made their decision based on data. For the PDS balance is needed between excessive robustness (with characteristic bureaucracy) and nimbleness.
An interesting aspect of the decision process is the role of managers and supervisors. During an interview, one of the engineering supervisors commented that if managers needed 100% of the information to make a good decision, then there was no point in having managers participate in the first place. The supervisor then continued to lay out his feeling that decision making should be implemented using the 80/20 rule. Decision makers should drive the team to look for the most value-added 80% of information (requiring 20% of the work) and then use experience and engineering judgment to help take the decision. The notions that this supervisor presented align very well with the experiences that I have lived through in product development. However, it is critical to add that the truly best engineering leaders take this one step further and distinguish when a 80/20 approach is adequate and when 100% of the information must be gathered.
FoM must come to a single understanding of which decisions are structural, and which ones are not. This understanding will allow us to ensure that our decisions our both of high quality and as rapid as possible. Failure to capture this understanding in the system leads to situations where decisions either take to long to get made, or are poorly made, with disastrous consequences.
At FoM PDO the decision process is conducted by both the engineering team and the leaders. Robustness and nimbleness is responsibility of all involved and is enabled by the product development system. Therefore future design of PDS structural interfaces should create links that allow for making good decisions and the generating full accountability amongst the participating individuals.
9.6.4 Perfect Execution Mindset
Plans, projects, architectures, designs, products - all we do must be done with a focus on seeking perfection in how we execute our work. Execution at the individual level has profound effects on the overall system and on a team's ability to deliver. Recent research in high performance teams suggests that emphasizing the individual and working together intensively as a team are concepts that are not divorced(Fischer & Boynton, 2005). When the individuals in an organization seek to excel and deliver the best they can at every moment, performance of the team becomes difficult for the competition to match. Seeking to acquire perfect execution at FoM PDO in the activities of every individual will enables the PDS to deliver its function in the best possible way. The PDS is however, is also responsible for encouraging a behavior standard of perfect execution.
174

Create accountability for actions by improving definitions of roles and responsibilities Demand a cradle to grave approach to product development
Select strategic areas of technical knowledge to keep in-house as a competitive advantage and driver of perfect execution Work on process definition to improve accountability and help clarify the expectations of perfect execution
9.6-one of the teams areas lacked a sense of good execution and the lack of well documented technical knowledge caused major problems All Other Examples - all examples presented would benefit from a team of engineers working to the tune of perfect execution
FiguPe 9-9 Character Element - Perfect Execution Mindset
It is difficult to say that lack of perfect execution has been the culprit for project failure. However, we can say that not aspiring to execute perfectly has severely impacted the performance of every engineering project we have presented in this thesis. Perfect execution is an individual and group aspiration and makes every action of the team easier and clearer. An FoM PDO the senior leaders have stressed repeatedly how in their experience perfect execution is probably the most sought after characteristic in teams and individuals. Executing perfectly means that every member of the FoM PDO team will work until every aspect of their design, validation and implementation have been completed to the highest standards.
At the PDS level, achieving perfect execution requires that we provide incentives and structure to the individuals and elements of FoM. Promoting perfect execution by taking actions at system level is not straightforward, and because of this, we have disaggregated perfect execution into three aspects that can be controlled. The three elements that we have identified are system level enablers of perfect execution that are based on multiple conversations with senior product development leaders and the lessons from the examples presented in the previous chapter.
* Accountability - clarity of responsibilities and empowerment to act * Technical knowledge - desire to purse increased technical knowledge in whatever area may
be needed and application of knowledge to solving problems * Systems thinking - embracing 'cradle-to-grave mentality' and interface definition,
management and design as key aspects of the job
175

For FoM, developing a perfect execution mindset enables the development of products that deliver high value and are successful in the market by ensuring we have done our work to the highest standards. Pursuing technical excellence as en element of perfect execution, the PDS can increase customer value by multiplying the probability of innovating. Systems thinking helps pull together the upstream and downstream implications of the product - its manufacturing, operation, disposal, renewal, etc - into product development, as well as integrate the interfaces as critical aspects of the development process.
The elements of perfect execution are also by the 'triangle of improvement' - technical knowledge, execution and initiative (Perez, 2007) - and align well with current best practices within the automotive industry. FoM must take care to avoid getting into situations were an excess of perfection makes our development process slow and non-competitive. Keeping our perfect execution mindset framed within a clear understanding that we work in an environment were there is scarcity of resources can help indicate where we have reached an optimal balance. The mindset of perfect execution helps create a vision. It provides the system with sense that what is done will transcend the individuals. Including it in our design of the PDS will help deliver our vital requirements and help generate the incentive in all elements to become a world class PDS.
9.7 Detailed Description of Elements of Form and Structure
Having identified five elements of structure for the FoM product development system, we will provide detailed description of each and architectural guidelines for implementation. The PDS uses the links amongst the elements of structure to deliver the system functions in the most resource economic mode. The architecture of the PDS provides the framework for these links to emerge in an orderly fashion. All decisions taken towards creating this structure support the delivery of the design goal, the system design requirements and the design objective.
Level -2
Level -
\I~~ --
Figure 9-10 Product development system structure with conceptual representation of architectural levels
The work in the next sections focuses on defining the systems at level -1 in order to deliver structure to the architecture at level 0. Future work to improve the product development system of FoM will
176

need to focus on developing the interfaces that are generated within level -1, the elements at level -2 and their relationships. A conceptual map of each level is presented in Figure 9-10.
The product development system must survive in an environment of limited resources, and therefore, achieving its design goal must be done in the most resource efficient manner. In business terms, this means making sure that we minimize the cost of our system and work on maximizing our return on investment. The design of the architecture for the PDS must therefore strive for the leanest solution possible. Optimizing our use of resources helps deliver on the design objectives for all major stakeholders. Lessons found throughout the thesis point toward using the 'product' as the central optimization element in the system. The product represents the customer's needs as well as the end product for the PDS helping the organization focus on adding value to the customer.
Product
Process Product
People Supporting DevelopmentInterface System Tools Supporting Supporting
Goals Supporting Spporting Supporting
Product Process People Tools Goals
Figure 9-11 Interfaces amongst elements of structure
In Figure 9-11 we present each of the five structural elements of the PDS and the first-degree interfaces that they generate. In the following pages we will look into the system level items (diagonal in black) and then provide the PDS architecture to enable further work on the other interfaces. At each interface - system, main, supporting - distinct elements of the value equation are defined and guidelines toward achieving a PDS that develops world class products are needed. The following bullet list describes each of these levels and provides direction in regards to the minimum aspects to be dealt with to achieve coherence.
System Level - the critical elements of each system are presented in relation to the delivery of the PDS goal. Guidelines for the PDS of FoM are given to present the system architecture. The objective of this level is to summarize the defining characteristics of each system and deliver the system level structure. The five systems are: product, process, people, tools and goals. For each the following sub-topics should be addressed:
o PDS Guidelines for FoM - guidelines that deliver the portion of the architecture assigned to the elements of structure
o Role in delivering the PDS System Goal -definition on how the system supports the delivery of the system goal
o Architectural Considerations - present additional characteristics of the system that must be considered for developing more advanced interactions amongst systems at lower levels
177

Interfaces Levels - interfaces among the remaining four systems will be presented and detailed definition at this level creates a link among all systems and customer value in a holistic manner. Each interface definition must deal with its effect on the overall PDS and integrate it with system level considerations and other main interfaces. The objective of the main interfaces is to create the operating linkages necessary for delivering world class products; primarily the interfaces must help us meet the vital system requirements. Each main interface influences the delivery of the PDS character and must be designed for alignment with the four elements of character.
The architectural framework for structure that we present uses system level guidelines to provide the structure for work on interfaces. Many multi-system interfaces exist and are governed by the guidelines provided. In this manner we can ensure that all interactions are taken care of.
9.7.1 Product
The product is inherently linked to and dependent on humans - customers, developers, manufacturing personnel - and as such, must be designed to comply with and work in the world of all humans. Both the needs of the customer and their expectations must be reflected in the product, these characteristics can be found both in explicit elements of form of the product as well as in feelings that the product evokes in people. True success in product development will deliver on both aspects. The figure on the following page summarizes the essential aspects of the product system.
Design guidelines for the product have been abstracted from the following sources: product development survey trip to Germany, interviews and conversations on design with Guillermo Aguirre (Aguirre Esponda, 2008), and interview and conversations on design with Jeff Deboer (Deboer, 2007).
THE ROLE OF PRODUCT IN DELIVERING THE PRODUCT DEVELOPMENT SYSTEM GOAL
The product is the center of the product development system and it is through it that product development delivers value to NAC. Good products will give the company competitive advantage by attracting customers and increasing the value proposition the company has to offer in the market. Good automobile designs have been timeless and provided their creators with decades of success, a look at Ford (Model-T), Porsche (911), VW (Beetle) are evidence of this. FoM must aim to deliver develop products that are of such quality that they endure the passage of time.
For the FoM PDS the product presents the value creation point. All design of the PDS evolves from an understanding of the product and the customer it tends to. Considering the guidelines presented for the product system they are all focused toward the customer and to delivering a design that at the minimum does not fail, the product must allow you to at worse not drive a customer away for ever. Any car that breaks down on the way to the beach for a family vacation will make sure the customer never comes back.
178

Mange product cost through active engineering risk management (Architectural Lesson: 4, Case: 11.5) Integrate suppliers with engineering process (Architectural Lesson: 6, Case: 11.5) Include the product architecture as part of the solution space (Architectural Lesson: 11, Case: General Concept) Prototype the product to achieve insight to detail and large scale interactions (Architectural Lesson: 20, Case: 11.4) Product includes elements and their structure, therefore include the interfaces as part of the design domain (Architectural Lesson: 22, Case: 11.6) Drive product innovation by creating team accountability for issue resolution (Architectural Lesson: 24, Case: 11.7) Solve product system issues through team work (Architectural Lesson: 25, Case: 11.7)
Design the product by removing error states (Aguirre, 2008) Design to ensure that the error states are left out inherently (Aguirre, 2008) Define the product by immersing the team with the product (Deboer, 2008) Design and develop the product concurrently at all levels of the system (interviews) Design the product for flawless implementation
Validate product on needs and expectations, focus on avoiding failure
Figure 9-12 Structure Element - Product
9.7.2 Process
Process sets expectations on interactions, information exchanges and times, therefore providing FoM PDO with means for coordination. Such is the power of the process that its definition can make a whole project succeed or fail. As a tool to create coordination it is key to carefully evaluate the consequences of our timing and deliverable decisions.
For FoM following process is even more critical given the relationship with NAC. The process provides an easy and transparent way to demonstrate progress on development programs.
179

Focus team on process discipline (Architectural Lesson: ALL, Case: General) Control project process to optimize the development time and cost (Architectural Lesson: 1, Case: 11.1) Define the product development process by backtracking from the instant of true value is generation (Architectural Lesson: 15, Case: General Concept) Develop and follow a process for change control (Architectural Lesson: 23, Case: 11.6) Challenge assumptions in the process as part of innovation; document the changes and results (Architectural Lesson: 13, Case: 11.3)
Focus the product development process on the value creation point of engineering - ESO (engineering sign off) Architect the process back and forth from the value creation point to capture upstream and downstream effects (Crawley, 2006)
Figure 9-13 Structure Element - Process
THE ROLE OF PROCESS IN DELIVERING THE PRODUCT DEVELOPMENT SYSTEM GOAL
The process in product development provides the direction for our development effort and creates cohesion for all the product development activities. By doing so it helps FoM coordinate amongst activities and sets the expectations of the team with regard to time and content. Following the process is critical but must be complemented with common sense, engineering judgment and discipline to change using the established processes.
Developing the right process can take decades, and FoM is lucky to have the support of NAC that has a world class product development process that considers the minute details necessary for brining a new product to market. However, FoM must be careful to adapt NAC's process to its needs, as the process has been design for coordination of thousands of engineers, not a couple hundred.
* People and process align through activities * Process provides structure to the process and initial structure to the organization. People
will align to activities and therefore process can work in line or against this
9.7.3 People
When considering the 'People System' we consider both individuals and the groups. Making sure that we understand the people are not machines for processing data (Pajerek, 2000) and that what
180

we can strive to control are behaviors is critical. Gaining an understanding of both these items can lead us to succeed at managing the 'people system' as an integral part of the PDS. People are the building blocks of the PDS and it is in people that the PDS becomes embodied to become a Product Development Organization. Ultimately, people execute, own and evolve the PDS and are therefore key to the system.
Mange product cost through active engineering risk management (Architectural Lesson: 4, Case: 11.5) Integrate suppliers with engineering process (Architectural Lesson: 6, Case: 11.5) Include the product architecture as part of the solution space (Architectural Lesson: 11, Case: General Concept) Prototype the product to achieve insight to detail and large scale interactions (Architectural Lesson: 20, Case: 11.4) Product includes elements and their structure, therefore include the interfaces as part of the design domain (Architectural Lesson: 22, Case: 11.6) Drive product innovation by creating team accountability for issue resolution (Architectural Lesson: 24, Case: 11.7) Solve product system issues through team work (Architectural Lesson: 25, Case: 11.7)
Design the product by removing error states (Aguirre, 2008) Design to ensure that the error states are left out inherently (Aguirre, 2008) Define the product by immersing the team with the product (Deboer, 2008) Design and develop the product concurrently at all levels of the system (interviews) Design the product for flawless implementation
Validate product on needs and expectations, focus on avoiding failure
Figure 9-14 Structure Element - People
THE ROLE OF PEOPLE IN DELIVERING THE PRODUCT DEVELOPMENT SYSTEM GOAL
The FoM PDO basic element is people. People become the embodiment of the PDS and as such the creators of value for the PDS. In the proportion that the people at FoM PDO align with its purpose and see value for themselves in the work they do the PDS will be able to work. People will transform
181

the need into product, and will key aspect in the value equation; their work aided by the process and tools will deliver the product, and goals will provide feedback on how they are performing.
FoM has focused intensely on people, their needs, motivations and providing excellent work life balance from its inception. FoM must make sure that every individual in the organization works and delivers to their maximum potential. For this product development to work people system guidelines for FoM provide a sustentative basis from which to grow this key system into the driving force of product development at FoM
9.7.4 Tools
The perfect tool should be transparent to process (Hale, 2007) and avoid dictating direction to any portion of the development system. However, knowledge of the capabilities of our tools shapes the most efficient interactions amongst systems. For organizations tools are easily seen as ways to improve particular aspects of product development, yet selection of the best tool is difficult. Tools must be paired to all other four elements of the system to provide effective support to increasing the delivered value of the PDS.
For FoM PDO all the critical information management tools for developing a new product have been already developed by NAC. However, there are many times one or two options from which to choose, and for FoM, choosing a set that is coherent and meets the needs of a smaller organization well is important.
The correct use of tools opens doors for seamless interaction with NAC. Selection and application of tools is an area that can remove some of the initial barriers to increase the amount of responsibility that is awarded to FoM. Tool usage can help create a benchmark between organizations and provide means to sell FoM's capabilities.
THE ROLE OF TOOLS IN DELIVERING THE PRODUCT DEVELOPMENT SYSTEM GOAL
Tools are enablers and are used by people to deliver value. Their influence on FoM will be greater than one would expect, because tools can easily drive changes in product development that distance it from delivering customer value. Tools are made to support the process and people who deliver customer value, but tools are not directly linked to the customer. Because of this they can quickly become liabilities if not properly integrated into the system.
Good tools provide the system with problem solving approaches and help eliminate the boredom of repetitive tasks. Information and data management tools are indispensable in information intensive activities such as product development, providing access to information for all parties who have need.
182

Select a congruent set of tools to avoid duplication of tasks and ensure alignment to the product development process (Case: General) Ensure that in global teams all parts involved use the same tools (Case: General) Develop and build prototypes as learning tools, as well as validation tools
Develop standard nomenclature as tools for communication, ensure team agreement (Architectural Lesson: 10, Case: General Concept) Use communication as the primary problem resolution tool, starting by the communication mean of greatest band-width available (Architectural Lesson: 27, Case: General Concept)
Integrate tool capability into PDS decision process
Define the product development process, then select a tool
Select the tool set that best fits the user community
Figure 9-15 Structure Element - Tools
SYSTEM IMPROVEMENT OPPORTUNITIES
* Selection of a congruent set of tools from the existing set, elimination of duplicate tasks and full execution of the selected subset to enable a diagnosis of tools
* Use tools to create transparency of information with global partners * Use prototypes as learning tools * Develop awareness of known tool weaknesses * Develop standard nomenclature as an enabler for clear communication; ensure team
consensus (Architectural Lesson: 10, Case: General Concept) * Ensure the correct tool is used for a problem (Architectural Lesson: 16, Case: 11.2) * Use tools to aid organizational alignment (Architectural Lesson: 17, Case: 11.2) * Use communication as the primary problem resolution tool - start by using the
communications mean of greatest bandwidth available (Architectural Lesson: 27, Case: General Concept)
9.7.5 Goals
The goals and metrics that FoM defines will change the direction it takes (Endo, 2008).Goals and the metrics we use to measure our progress towards them represent, for the product, an abstraction of
183

the customer needs. For the rest of the system, goals and metrics provide a way to ensure that the development process is moving along the right track. On an individual level, the goal and the metric will generate incentives and these will, in turn, frame the decisions the individuals take. In aggregate, organizations work in similar manners, with goals and metrics being critical to how they evolve over time. Setting goals and metrics is equivalent to the art of setting up a problem.
Metrics and goals for the product development organization was the first complimentary thesis to be developed and as such a system metric has been developed and will be presented.
Implement a general organizational metric that integrates all three stakeholders
features provied by the PDO Engmeering Participation Metric =
total features EPM EPM EPM
Decision Variables = - ,cost ' time ' performance
Endo 2008 Develop aligned team goals to promote a liquid organization
Integrate motivation as incentive to achieve project success
Goals for product, individuals and teams must align in the product development organization Process moves forward by setting goals. Only goals that are clearly an important part of the process will become meaningful Goals must be directed at driving product results and targeted at generating organizational alignment Goals drive behaviors
Goals are one of the most effective communication tools for management
Figure 9-16 Element of Structure - Goals
SELECTED METRIC
The metric developed for FoM considers the overall participation of the PDO in NAC, the influence of Mexico and some of global factors that affect the PDS by providing decision variables that align with all systems (Endo, 2008).
184

THE ROLE OF METRICS IN DELIVERING THE PRODUCT DEVELOPMENT SYSTEM GOAL
The metrics and goals reflect the delivery of value by considering that an increase in the number of features that is provided by the PDO can only increase if the previous set of features were successful in the market. Both innovation and reduction in the use of resources are subsequently addressed by the three decision variables. The metric therefore covers the whole spectrum of the PDS and deliver on the need to measure its change in performance going forward.
9.7.6 Interfaces Among the Elements of Form
The five elements of form that make up the structure of the PDS relate with each other continually, and all must be present at any point in time to allow product development to occur. The interfaces among the five systems - product, process, people, tools, goals - are of the utmost importance to the product development system, and their definition is critical to the design of the PDS. These interfaces are, however, of great complexity as they touch upon many different aspects (social, technical, managerial, strategic and many others) and present a significant challenge for those who attempt to define them. We have approached this problem by specifying guidelines for each of the elements of form to allow the PDS to grow organically.
Definition of architectural structure guidelines for the five elements allows the organization to implement the PDS architecture in an organic manner. Organic growth allows the organization to solve the many interactions of form elements within the PDS without needing to enlist every possible relation. It also presents an opportunity to better match the design of the system to the realities of the business environment today. The organic approach to the implementation of the PDS is presented in detail in chapter 12.
Design of a product development system requires keeping the interfaces amongst the many elements clear to all those involved. The guidelines presented help clarify some of the issues that arise yet, it has been seen that a process to evolve these guidelines and select the areas for work and the actions to impact each element of form is more effective. The interfaces in the architecture for the PDS are therefore kept aligned by the PDS concept and the guidelines for elements of form.
185

9.8 Architecture of the Product Development System
Presenting the complete architecture for the PDS in a single condensed form is critical to cascading
it through the organization and achieving implementation. The architecture for the system is the
aggregate of the concept for the PDS and the detailed architectural guidelines and considerations
from elements of structure and character.
Communication Flexibility
Decision Process
Perfect Execution ,
Figure 9-17 PDS Architecture Diagram
Architecture of the PDS: A Product Development Organization with an aligned set of form
elements (goals, people, process, tools and product), that allows the product development organization to deliver an uninterrupted flow of information from customer needs to
finished design by mastering excellent communication, flexibility to adapt to changing
requirements, robust engineering decisions and perfect execution of all activities.
The diagram presented in Figure 9-17 presents an abstraction of what the architecture for the PDS
is. All product development organizations need to have goals, people, processes, tools and a
product, however, these elements alone do not take us in the best path from customer needs to a
finished design. These elements depend on how the organization executes; and communication,
flexibility, decision process and perfect execution can guide the way toward better product
development. The diagram helps convey that FoM will work to ensure that their structure elements
become aligned to the concept of enabling improve information flow from customer needs to a
finished design.
The architecture for a system is the value proposition, as established by the cost to performance
relationship, that structure and character provide a product or entity (Aguirre Esponda, 2008). For an organization the architecture is key in defining the business strategy to be followed. The business
model for an organization can grow from the architecture and define how the firm will compete in
186

the market. For FoM understanding what the business strategy is will be important to compete effectively in an aggressive market of low cost engineering providers. The value proposition defined by the architecture presented, is to provide value by insuring a clean path between needs and finished design by executing the work right, adapting to change, making the right calls and communicating with diverse teams.
Business models can be tested by evaluating their added value, robustness and offensiveness(Casadesus-Masanell, 2006). Evaluating the PDS architecture identifies areas that are still largely incomplete. For this reason during implementation of the PDS one of the areas that must be worked on is to improve the completeness of the business model. The architecture provides progress in all of the three areas suggested, yet well directed work will be necessary to achieve a well rounded business model.
The architecture and concept for the PDS provide foundations for improving the FoM PDS. Proper implementation is necessary to reap the benefits of having completed this work and moving FoM closer to achieving its long-term vision. Even with this, examples of how the development of the PDS architecture has itself impacted the organization are presented in chapter 10. Direction, structure and clarity of purpose are achieved through developing the architecture.
9.9 Key Takeaways - Product Development System Architecture
We have set off to improve product development and, in doing so, have sought to design a product development system that facilitates this. To achieve this goal deep inquiries into the various aspects of PD have been done and this chapter summarizes this work by developing the architecture for the PDS of FoM.
The key insights of this chapter relate to the architecture. One question that comes to mind is in regards to the completeness of the design presented. For this we find guidance in the deliverables of the architect (Crawley, 2006). The following is the list of deliverables followed by the section of the thesis or chapter where the information is located with a brief review of how each has been delivered.
1. A clear, complete, consistent and attainable set of qoals - Section 9.3 o Product Development System Goal: To enable the growth of a world class
automotive product development organization that delivers premium added value to customers with lower that average cost and time
o Vital few requirements- the product development system must: * Develop products of high customer value that are successful in the market
place * Direct the product development efforts at FoM in alignment with
corporation * Solution of development problems
187

2. A description of the broader context in which the system sits - Section 9.4 o Described in detail by using three sets of characteristics
* Local PDS characteristics * Geographical context characteristics * Global characteristics
3. A functional description of the system, with at least two layers of decomposition -Section 9.3, Chapters: 2, 3 and 8
o Delivered a full list of design objectives describing in detail what the product development system is meant to do.
* Twenty six design objectives in all (see Table 9-2 Design Objectives for the FoM PDS by stakeholder)
o Analyzed the source of value for the customer o Analyzed selected case studies from actual PD examples
4. A concept for the system - Section 9.5 o Concept: To create an uninterrupted flow of information from customer needs to
finished design by mastering excellent communication, flexibility to adapt to changing requirements, robust engineering decisions and perfect execution of all activities.
5. A design for the form of the system, with two layers of decomposition - Sections: 9.7, Chapters: 5, 6 and 7
o Developed specific architectural guidelines in section 9.7 and provided detailed analyses of the elements of form in Chapters 5, 6 and 7
6. A notion of the timing, operator attributes, cost, risks, and the implementation, operation and evolution plans - Chapter: 10 and 11
o Documented current implementation examples o Provided process and guidance to achieve implementation and evolution of the PDS
architecture 7. A document or process that ensures functional decomposition is followed, and the form at
interfaces is controlled - Chapter: 11 o Presented evolution and implementation processes and guidelines with sufficient
detail to ensure functional decomposition is followed.
All of the deliverables mentioned by Ed Crawley have been completed throughout this thesis and we can therefore say with more confidence that an architecture for the PDS has been successfully developed.
188

10 The Organizational Effects of Designing the Product Development System
The architecture for the product development system has already begun to show some promising initial effects at Ford of Mexico, the organization chosen as a case example for the design of a product development system. Work to build the PDS involved many hours of work with Ford of Mexico's upper management discussing concepts, principles and direction for the product development organization. These discussions resulted in the early adoption of some of the key ideas identified in this thesis. It is the effects caused by the early adoption of these key ideas that allows us to review how the PDS has influenced the organization.
To review the effects of the PDS, four examples have been selected. The selection has focused on finding those areas where change in the organization can be well correlated to the effort to improve the product development organization. The four effects that have been selected to present the influence of the PDS architecture are the following.
1. An innovative approach to project team setup 2. A redefined and redirected organizational strategy 3. The inclusion of selected strategic topics in the organization's leadership discussions 4. Increased emphasis on the solution of systemic problems
These four effects are presented in more detail in the following pages. The effects are presented along with the architectural concepts that triggered the change in the organization. It has been the intention to provide only as much detail as is necessary to understand the effect of the PDS on the FoM Product Development Organization for increased clarity. For each case the situation, effects and summary are described.
1.0.1 New Approach to Project Team Setup SITUATION
Project teams can be setup in different manners eliciting varying degrees of team performance. Ford of Mexico had traditionally followed normal practice within Ford and staffed its programs based on headcount prediction models. At present, however, these models are based off projects that involve on average in excess of 200 engineers and thrive in an organization that has in excess of 10,000 engineers. At Ford of Mexico the organization has around 230 engineers (total) and projects are proportionally smaller. As a result, setting up the team requires a different approach, one that maximizes the smaller size of the Ford of Mexico organization and its competitive advantages.
EFFECTS OF THE PDS ARCHITECTURE
This thesis has found that improvement of communication for product development teams is well correlated to the performance of the team. Some of the variables that were found to influence the
189

communication amongst team members were team size and the distance between members. Both of these variables can be controlled and improvement in the team's communication and performance are therefore feasible.
Small sized teams at Ford of Mexico had been a necessity for a few years. Only recently has the organization reached the 200 engineer mark, yet previously had averaged 100 engineers. With growth, keeping engineering teams small in size was not always easy, as the temptation to increase the number of people involved to solve a problem was always there. However, having identified small team size as a way to increase the performance of the team, Ford of Mexico launched a pilot team to test the effectiveness of this action. Some of the results from this decision have the growth of a project team that is quick and efficient to coordinate, as well as very well integrated. Being able to keep small sized teams in a deliberate manner has been important to the pilot team's success.
The distance that exists between two team members has a direct relationship to the probability of two communicating. At the product development office of Ford of Mexico the distance amongst team members can vary anywhere from adjacent cubicles all the way to 30miles (the distance between the two main PD buildings). Tensions between motivations to cluster teams by function or by project always exist, and selecting the optimum model is never easy. In this thesis the research done pointed toward developing project-biased team clusters to foster cross-functional communication and incentivize good team work. Using this information and previous experiences with both function and project biased clusters it was decided to form tightly knit project teams that would all be located in one area of the building. Results from this decision have been apparent in the excellent team dynamics and the obvious communication that takes place amongst the team. Communication has increased significantly and so has the initial teams capability of solving problems.
SUMMARY
Creating teams that are able to make good decisions, are well motivated and willing to take on challenges is desirable in all organizations. During Ford of Mexico's period as a very small PD organization, teams with these characteristics were the rule, yet it became clear that with the growth of the engineering population this was no longer the case. Actions to correct this situation were taken, with the most important ones outlined above:
* Small team size * Close physical co-location.
Finding these factors and providing them adequate support to enable implementation was in great part the consequence of embarking on the quest to find a way to truly improve the PDS. As a result today there are at Ford of Mexico two excellent examples of the impact these actions have had on team motivation, performance and disposition.
190

10.2 Redefined Organizational Strategy
SITUATION
Defining the strategy for an organization is never an easy task and for Ford of Mexico new challenges and the growth in size have meant that evolution of the strategy has been mandatory. Selection of what elements to include in the strategy and how to prioritize them in the best possible order has been at the epicenter of a huge ongoing effort at Ford of Mexico to define the organization of the future. The importance of doing an excellent job at defining these directives for the organization has made achieving consensus on the strategy a tough job. Even so, creation of a solid strategy that can pull the organization through the next 5 to 10 years must be done to ensure the futures competitiveness of the organization. Ford of Mexico has acknowledged the challenge that this situation presents and worked to achieve clarity and definition in its strategic direction.
EFFECTS OF THE PDS ARCHITECTURE
The architecture for the product development system required finding the key elements that must be present in a successful product development organization. To select the elements that were relevant to FoM and refine them as best possible work in collaboration with the leadership group of the FoM was done. As a result of this exercise it was found that the most important element is the people, who are the basic building blocks of all organizations. Other elements were found, an example of which is the importance of the quality of execution in all activities. The PDS architecture has integrated these two elements and seven others into a coherent framework for the organization.
People have always been central to the strategy that FoM has followed. Within the architecture for the PDS people were also identified as key to the success of the system and highlighted the implications of this aspect of the organization. For example, the importance of growing adequate technical capabilities were seen as a true inhibitor to faster and better product development during the adaptation of the new diesel engine (case example - section 8.5). As a consequence additional specific aspects of the role of people in the organization were added to the strategy. The successful alignment of findings coming from the development of the PDS architecture and the existing organizational strategy has helped clarify and evolve ongoing efforts to improve the strategic people aspect of the organization.
Adding value requires that the tasks an organization sets out to accomplish are conducted with high quality, low cost and in the least possible time. In small organizations achieving these delivery characteristics can be done with relative ease, yet the larger the organization the more complex it becomes. Within the architecture for the PDS achieving perfect execution was identified as one of the drivers for achieving delivery of the organizations vision. The strategy for Ford of Mexico evolved and presented these delivery characteristics as follows: ensuring that the organization achieved efficient, nimble and clean execution in all its activities. These additions to the strategy help ensure
191

that increased added value through perfect execution remains at the core of Ford of Mexico's strategic direction.
SUMMARY
Good organizational strategy requires a deep understanding of the organization at hand and of the business environment in which it exists. For Ford of Mexico a variety of external factors make selecting the right strategic course a difficult task. Through the development of an architecture for the product development system all elements that affect the organization were studied and gave way to a unified insight, the PDS architecture. Implementation of some of these insights to the organization's strategy has been almost transparent, enabled primarily by the similar levels of abstraction that both strategy and architecture deal with. Many of the elements identified by the architecture and the intuition of the organizations leaders matched, a fact which helps validate the architecture to some degree. Based on the experience to date, the deep understanding of organizational factors presented as support to the architecture will help open the way for sound business and organizational strategy at Ford of Mexico.
10.3 Strategic discussion amongst FoM Leadership
SITUATION
The leadership team in an organization is continually involved in discussions that are strategic in nature to ensure that the long term viability of the organization is maintained. At Ford of Mexico the last few years have brought significant changes in regards to what the future of the organization appears to be. As a result the content of strategic discussions amongst the leadership team have had to evolve to adapt to these changing conditions. Identifying which elements will become important under new conditions is never easy, yet the future of an organization depends on the ability of its leadership to identify the challenges ahead and prepare for them.
EFFECTS OF THE PDS ARCHITECTURE
High quality strategic discussions have always been a staple mark of the Ford of Mexico Organization. With the development of the architecture for the PDS opportunities to enrich these conversations and add new topics of conversation were created. The necessity to achieve alignment in what the PDS architecture should be and the participation of external agents in the process opened the way for much of this change. Discussions deriving from these new elements have been of high quality and broadened their scope.
Delivery and implementation of the PDS architecture has required the leadership group to meet on a regular basis. Biweekly meetings between the management of Ford of Mexico and the employees involved in the MIT-SDM program began to take place to create alignment amongst all participants. These meetings have benefited from the presentation of a variety of cutting edge theories and knowledge from MIT to improve product development. Discussion derived from exposure to these
192

new ideas has created spirit of inquiry and holistic thinking that has derived in important resolutions, such as that of defining the ideal profile for teams and engineers. The need for alignment created by the development of the architecture has therefore catalyzed efforts to improve PD activities and is quickly becoming a forum for key strategic discussions.
The interaction with MIT that was necessary to develop the PDS architecture opened an avenue for scrutiny of the current status of FoM that quickly surfaced some of the more pressing needs. The more noticeable of these interactions included a trip of MIT faculty to the Ford of Mexico facilities. During this trip a brief review of the current status of FoM and future directions was conducted, culminating in a few extremely valuable conclusions. One of them was the need for FoM to create an adequate plan for replacement of supervisory level engineers that were nearing retirement age. Although this problem had been previously identified, in the context of a growth program that includes further technical development it took on its true dimension. Some of the findings regarding people development that were found as a result of the PDS architecture gave guidelines for what actions to take and were implemented. The interaction with MIT faculty resulting from embarking on a definition of the architecture for the PDS has provided some of the most noticeable short term effects.
The culture of the organization and how it changes with size and composition is a fact that had been painfully obvious to the FoM management for some time. An organization's culture is heavily influenced by the tacit assumptions the group shares and, to some degree, determines how group members will behave. For product development, the culture of the organization has been seen to have significant influence on the performance of the group. Both academic and real world examples of the influence of culture on the PDO results were registered during the definition of the architecture for the PDS. At Ford of Mexico the input from the architecture and other events triggered an effort to define the organizations culture and then embark on imprinting it on the group. The architecture for the PDS has helped give this initiative direction and provided some background to support it. With the ongoing changes in FoM environment being able to start defining an ideal culture that is well integrated with actions in other areas of the organization has been an important next step in the discussions regarding the organizations culture.
SUMMARY
The architecture for the PDS has had some instances in which it has directly influenced the organization. However, in some of the more interesting cases, the architecture has provided a structure and starting point for discussions that would otherwise be difficult to have. Creating the right forums and enhancing the information and theories available to the organization have been contributions that have been as valuable as the conclusions drawn by the architecture itself. In the instances described in this sub-section, much of the progress can change has been the result of working as a group. It has been seen that with each effort to further clarify specific aspects of the architecture better and more attractive areas for improvement have been identified. Indirect effects of the architecture have become themselves enormous areas of opportunity.
193

10.4 Emphasis on Solution of Systemic Problems
SITUATION
The essence of an organization that makes continual progress and improves upon itself is its ability to learn from past mistakes. The process of learning can take on different shapes, yet one of the more important ones is the ability to implement solutions that have effect on how the system. At Ford of Mexico, as in other organizations, opportunities to learn arise at every moment. Channeling these opportunities and transforming them into lessons that make the organization more effective is a task that must be mastered.
EFFECTS OF THE PDS ARCHITECTURE
Changing process is one of the most direct ways to learn. Integrating the lesson into the steps of a process ensures that from that moment on all who follow the process will be applying the lesson the organization learned in the past. For Ford of Mexico this concept was clear; however, balancing a remotely generated corporate process with local lessons presents an additional challenge. The PDS architecture delivered insights into the kinds of systemic issues that are found in the current processes and proposes guidelines to improve. As an example, for one of the newer product development projects, Ford of Mexico has aimed for concurrent project schedules with its US counterparts following one of the guidelines established in the architecture. In aggregate, the architecture and Ford of Mexico's focus on learning have the potential to drive true system level improvements.
Applying and learning from the knowledge and research being brought back from MIT has presented a new problem for Ford of Mexico. The PDS architecture proposes areas of opportunity and further detail is under development by the whole MIT-FoM team, yet implementation of them requires discipline. This creates a need for a systematic approach to implementation of change. To this effect, Ford of Mexico has begun to develop a process with the intention of finding a solution to implementing organizational change that is systemic. This process helps the organization increase its ability to select the right areas for action and push the proposals all the way from concept to implementation. The new problem created by the interaction with MIT has therefore opened an avenue to find a systematic way of driving change and improvements into the organization.
SUMMARY
The PDS architecture has generated new needs within the organization and as a result impacted areas other than that first targeted. The process to implement change grew out from FoM need, yet became an important element of the PDS architecture and its implementation. The systematic approach taken to develop the architecture allows the right kind of feedback from the organization and enables a two way communication channel. This two way communication and the framework presented by the architecture has helped the organization uncovered latent problems and areas of great opportunity.
194

10.5 Key Takeaways - Effects of the Product Development System
The registered effects of the PDS architecture up to this day are a consequence mainly of working to develop the architecture. Even so the effects have been positive and satisfactory. For FoM the development of the PDS has provided an opportunity to explore new realms of thought and pursue questions of strategic importance.
The chapter has given way to four key takeaways:
1. Architecture affects structure, capability and culture
The effects registered at FoM touched upon the three main levers of an organization: structure, capability and culture. It is hypothesized that this is a consequence of the how core the architecture is to a system and the depth of the work needed to develop it.
2. Approach is as important as result when developing a system architecture
Most of the effects registered are a result of the approach followed to develop the PDS architecture and yet a direct effect of the architecture. We can therefore support the notion that for this architecture how we approached its development has been as important as the end result.
3. Architecture implementation generates new questions
Implementation of some of the concepts and framework from the PDS architecture gave way to more and deeper questions. By providing order to complex ideas and problems the architecture allows the team to revisit a problem and question the true cause for problems. This process can lead to finding what the real problems that an organization needs to solve are.
4. Development of architecture helps gain insight to time, cost and risk
Although the effects of the architecture have been preliminary they help visualize what the time, cost and risk of the architecture might be during implementation. Developing the architecture is by itself, a first exercise to gauge the size of the problem that lies ahead for the organization.
These key takeaways provide support to the task of generating an architecture. For an organization the investment in time and cost to fully understand a problem and create a concept for its solution can well be worth the investment.
The effects registered to this moment are encouraging. Continued work in this direction will help FoM continue on the maxim established by Schaffer & Thompson.
Successful change programs begin with results. (Schaffer & Thompson, 1992)
195

11 Next Steps for the Product Development System of Ford of Mexico
The architecture for the PDS has proven its value as seen through the initial effects registered at Ford of Mexico. However, achieving the vision set for the organization is still far away. Closing the gap between the organizations current state and the goal we have set requires bringing down to earth some of the high-level concepts used to create the PDS architecture. Some of these concepts will require extensive work to understand the essence of complex multidisciplinary problems to
develop implementable solutions, yet others are ready for implementation today. Changing the organization to achieve its proposed vision will need of both short and long term actions and results.
To implement the PDS architecture we must create both alignment and coherence amongst all actions, and space for the short and long term actions. We have divided this problem into a total of four building blocks that together help deliver our vision for FoM: 10 work areas, actions for implementation today, future actions and organizational implementation guidelines. The PDS architecture presents a concept and vision of what se have identified today to be a desirable product development organization. These concepts are drawn down to earth and presented as work areas that contribute to the delivery of the PDS. Actions and tasks that the organization must work on to improve each of the ten areas are either actions for implementation today, or, future actions. For each identified action, guidelines learned from past success stories of organizational change help lead initial deployment in the organization. Finally, well aligned actions that have robust plans for implementation enter the organization to help close the existing gap. This process is shown conceptually in Figure 11-1, going from architecture to implementation in the organization.
4
Oa ao
4 'J
Figure 11-1 Implementation diagram for the PDS architecture
This chapter is dedicated to describing future work required to achieve implementation of the PDS architecture. Each of the four elements described in the diagram is presented in one sub-section of the chapter presents the key elements of each. In each case the organization has only recently begun to work on these elements and they are therefore considered future work.
196
!Iroretto ~II
Y gas. .,
............. r s a .; ~ -r: :: ..............

11.1 From Architecture to Workable Areas
Organizations need to have well planned work and goals in order to make progress and by nature architectures are not well suited to this task. We have therefore a need to take the PDS architecture and present it in a manner that is conducive to organizational change. Creating work areas has been identified as a format to achieve this goal. Each work area helps drive the organization toward meeting one or more of the concepts identified by the architecture and helps create work plans and goals toward change in the organization.
Selecting the right work areas for the organization is critical to ensuring they direct work along the right path. This thesis presents the three sources of information to select these areas: literature review, case examples and architectural guidelines. The thorough review of previous work done in the area of product development and organizational change provides insights to best practices from other similar efforts. Case examples that have been analyzed present the real needs of the organization. And architectural guidelines help create alignment to the PDS architecture. All of these information sources were reviewed and a condensed list of eight work areas was selected. The ten areas selected therefore present a well-documented initial direction and grounds for evolution in the future.
Concept Form
1. Incentive system X X x 2. Continuous improvement x x X X x 3. Eliminate information flow inhibitors X x X
W 4. Process discipline x X x x X 5. Hands on engineering X X X x
o 6. Leadership and teamwork x x X0E 7. Culture x X 8. Customer focus x X X 9. Design Philosophy x X x x x X 10. Tools X X
Table 11-1 Work areas to concept and form map
The ten work areas relate to each of the nine fundamental concepts presented in the PDS architecture. The matrix representation shows this relationship by cross-referencing each work areas and elements of the PDS architecture concept and form. In each case there are lead relationships that have been highlighted with a capital mark X in bold and secondary relationships. Mapping the work areas to the architecture is critical to ensuring alignment in the organization.
Work areas are better suited to generate implementation of the concepts depicted in the architecture. For example, it is difficult for an organization to organize and work to improve flexibility per-se. On the other hand focusing the organization to work to developing a people that
197

exhibits characteristics associated with 'hands on engineering' is simpler. Work areas also provide better fit to the organization in that we can define a plan and actions for immediate implementation while remaining ready to incorporate new findings in each work area. Work areas therefore translate the abstract concepts of the PDS architecture into the every day language of the organization.
Variations in the organizations environment and its growth will change the gap that exists between the current status and the future vision for the organization. The work areas must change to focus on those aspects that need the most improvement and remove work areas that have proven to be ineffective or have been fully explored and implemented. Additionally the improvement of the organization depends on the ability of the plan to integrate inputs from members of the organization without losing its direction. Using work areas allows us to redirect our effort without losing our strategic direction. [See: Figure 11-2]
I Ue
l ' F rt- Figure 11-2 Evolution of work areas
Definition of the ten initial work areas is fundamental to pursuing change in the organization. Through the work areas we can define the opportunities available to us today and design processes to ensure that the right actions are implemented in each case. Initial work areas also play an important role by enabling the organization to begin a structured discussion to find the areas of most opportunity and enrich the organizational change plan. Initial work areas can help start the desired change within the organization and will help create alignment and continuity.
The work areas play a critical role in helping us make the PDS architecture actionable. To this extent we will use the work areas to structure the implementation and evolution aspects of our future work. The eight work areas summarize key opportunity areas identified during the development of the PDS architecture and will help the organization start moving toward achieving its vision.
Gen. 1
C, C, t e H
Implementation Actions
198

11.2 Opportunities for Immediate Implementation of the PDS
Project success requires that quick and early results be available. The development of the PDS architecture uncovered areas of immediate opportunity that can quickly become actions for implementation. These actions are tasks that the organization can immediately embark on to begin making progress toward improved product development. These actions are an opportunity to deliver the early results necessary to seek larger opportunities in the future.
The opportunities and guidelines for each of the work areas are summarized in the Table 11-2.
Work Area Guidelines
1. Incentive system Use accountability to drive incentives Align incentives and desired culture
Focus on end state find improvement oportunities2. Continuous improvement Use hypothesis as learning tools
Improve by changing system and documenting situation Use standard communication procedures for coordination and informing (location, content, source and purpose) Use communication channel of greatest band-width that is economically feasible Use standard coorporate tools (WERs, AIMs, etc) to improve
. Eliminate global communication3. Eliminate information flow Know all decision makers and stakeholders inhibitors
Drive data driven decision making Understand full process up and down from the value creation
4. Process discipline point
Work with suppliers 5. Hands on engineering
Use prototypes (virtual or real) to learn Lead through technical knowledge Keep team motivated6. Leadership and Avoid assymetries in the decision processLead by removing barriers Integrate individual and coorporate culture Develop flexible engineers by seeking well balanced depth andbreadth; start with depth Align culture and incentives
8. Customer focus Cradle to grave approach to product development Focus the vital few requirements to avoid failure One coherent design philosopy
9. Design Philosophy Design and develop the product concurrently at all levels of the system (interviews) Use congruent and aligned tool set
10. Tool Usage Know the tools weakness Ensure right tool is used for the right problem
Table 11-2 Guidelines and opportunities for work areas
199
Actions for Implementation
Deploy full project delivery targets as individual performance items
Conduct a search of all corporate lessons learned processes and tools, and make them available to all the engineering Select a lessons learned process, method and tool for the organization
Locate project teams in close proximity to increase communication
Communicate decisions in a written manner Develop excellent long distance communication abilities: phone conferencing, video conferencing, net-meeting and Develop clear functional linkages to technical experts in the corporation Increase technical knowledge in the engineering communicty Maintain international liaisons to bridge geographically distant teams
Develop training curriculum to enhance communication skills for engineers Develop communcation protocols for project teams Gain control over the project process timing
Define the value creation point for all our processes Define and create list of decisions that must be taken by the engineering management team Develop a list of activities that define what 'hands on engineering' is Develop a list of strategic areas of technical knowledge to develop within the organization
Develop a checksheet for datadriven decisions Keep organization close to full capacity utilization
Develop a charter that describes the FoM culture
Have project teams communicate with marketing to check project direction at least once per month
Create a design phylosophy handbook
Develop list of right corporate tools for each job description Develop buck testing capability

Leadership is needed to help drive change into the organizations. The list of work areas and implementation actions though a live document helps leaders define the territory where the organization will operate. For management and leaders in general the ability to define this territory via operating limits and standards that show people where they stand is crucial for leading change (Shapiro, Fall 1984). The matrix presented both helps managers exert their leadership and requires of their ability to begin changing the organization.
Improvement actions require time to implement and then for their effects to become measurable. In addition to leadership, a process must exist to structure the development of actions for implementation, track their progress and document their effectiveness. One way to achieve this is by developing a process that designates the stages through which each improvement action must pass and minimum deliverables at each stage. Widespread use of similar tracking methodologies within the corporate environment suggests that this method can be appropriate and easy to adopt. Ability to track and register the effect of our improvement actions increases leaderships understanding and control of the improvement process and provide levers to remove possible road blocks.
Status Summary SW
Plan i I mplement
Figure 11-3 Concept for implementation action process
Conceptually, a process for driving improvement actions should enable organized management of the ongoing efforts and achieve closure of all initiative. The concept presented in Figure 11-3 depicts transition through six stages and the use of two central process sheets. A refined process of the kind suggested will be necessary for the organization to capitalize on a change initiative.
The trilogy of an action plan, leadership and a process to implement change must exist to increase the odds of success for organizational change efforts. Together these elements can help the organization show initial progress toward implementation of the PDS architecture and gain support for more ambitious endeavors.
11.2.1 Systems Engineering Organization
Change in an organization is an ongoing process, not a discrete event in time. Leadership, process and list of initial actions can only go so far, continued work calls for an additional element. Keeping
200

improvement efforts alive, finding new areas of opportunity and brokering solutions for multifunctional problems benefits from having support of a team that is prepared and empowered to meet these challenges. Characterizing the attributes of a team that can achieve continual improvement for systemic issues is for that reason required.
The problems that have been found to be the most difficult for the product development organization involve technical knowledge, many stakeholders and disciplines. System engineering, as a discipline, is uniquely positioned to meet the challenges posed by problems like these. Understanding the relationships among all of these elements and finding solutions to them is at the heart of the work done by systems engineers. Solving the complex problems identified in the research for this thesis can benefit from a systems engineering approach.
Creating a system engineering team is one way to solve complex multi-disciplinary issues. Other companies have followed this approach to the problem in the past with a high success rate. System engineering organizations provide a framework for creating a team with the right abilities and knowledge to tackle the systemic issues that plague product development organizations. For Ford of Mexico creating a system engineering team would deliver benefits to an organization that has always instinctively followed a systems engineering approach, but has never formalized it as a team.
A systems engineering team would work to identify, solve and manage the ongoing efforts needed to accomplish true change within the product development organization of FoM. Individuals within the team would be tasked to analyze and engineer solutions to new vehicle projects, processes, new technologies and issues in functional areas. All efforts from the team would be directed toward creating a PD organization that meets FoM vision for PD in the future. At the center of the greatest issues in product development, those that involve experts from different technical arenas and inputs from many functional areas, a systems engineering organization could help FoM meet a profound transformational challenge.
There is great risk that true implementation and change will not be achieved when embarking on an organizational change effort. Reducing this risk requires being able to identify a team that is accountable for the delivery of improvement actions. The existing teams within FoM (project or functional) are not well suited to responding to these challenges or becoming accountable for delivering system level improvement actions. A systems engineering team can become accountable for these initiatives and reduce the risk of not delivering the improvements required of the PD organization.
Ford of Mexico is today in a unique position to transition from a young growing and learning organization into a world-class product development group. Achieving this transformation requires taking the best of what is available today and improving on all those problems that have afflicted other organizations in the past. This effort will need continual support and organized evolution of the actions needed to achieve progress. A systems engineering team would help Ford of Mexico manage and improve its improvement efforts leading toward the desired transition into a world class PD group.
201

11.3 Charter for Evolution of the Product Development System
Implementation of the PDS architecture still requires much work at all levels of the organization. Ford of Mexico has embarked on a program with MIT to participate in the Systems Design and Management program and has currently sent two employees per year for the past three cohorts to obtain a masters degree. As an important portion of their work at MIT, FoM employees must complete a thesis that combines management and engineering topics. These theses become a great opportunity to develop the detail necessary for the implementation of the PDS architecture and can provide FoM with the much needed implementation actions.
Detail Dei n
Figure 11-4 General FoM-MIT/SDM PDS architecture evolution plan using thesis
The figure above [Figure 11-4] presents the overall plan and approach developed by FoM to use linked theses to find the improvement opportunities all along the PD process. To start the organization worked on developing the idea behind the plan presented above. Almost in parallel, the concept for the PDS architecture was developed for the FoM PD organization of the future, along with a measurement system to track the organizations progress. From here, initial concepts for improvement have been derived (presented in section 12.2) and guidelines to organize the linked thesis are suggested. The next steps are to evolve the concept presented in the PDS architecture and more importantly begin finding specific areas of improvement.
Approaching the evolution of the PDS by using linked theses stems from the belief that in normal business context, finding solutions to the largest challenges of PD is not possible in isolation. We have summarized this idea by creating a hypothesis regarding why we expect our approach to work.
Hypothesis (finding solution to systemic problems): If difficulty in finding solutions to systemic problems in PD is related to the approach taken, the lack of knowledge, motivation and the available time, then providing a combination of education to improve the taken approach, knowledge and mindset combined with time to reflect will facilitate solutions to systemic problems.
202

It is our intention at FoM to increase the number of systemic PD problems that we solve for the growing organization. If the hypothesis above is true, then, by participating in the SDM (Systems Design and Management Program) and effectively applying the lessons learned FoM will find ways to change the independent variables in the hypothesis so that solutions to systemic problems will be possible. At the moment, initial observations appear to support the hypothesis. Examples have been presented in this thesis as the impact that the PDS architecture has already had on the FoM organization. The hypothesis will be validated with each generation of students that attend the SDM program, and will help FoM identify if the program is facilitating the intended changes. Continued work in this arena will help FoM find solutions to systemic problems that characterize the best product development organizations.
Figure 11-5 Role of thesis in generating evolution of the PDS architecture
In Figure 11-5, the general process for focusing sub-sequent theses is provided. Each employee/student will have knowledge of the end goal for FoM and the current status of the organization. In addition, there will be a list of the work areas that are currently being worked and the actions being implemented for these work areas. Using this information and guidance from FoM management, it is the students' responsibility to find the most effective ways to improve on what is currently being done in FoM PD. The work areas, future vision and PDS architecture help create continuity amongst the theses. Continuing to refine the plans and activities for transforming the PD process and measuring the effects of each major initiative will keep the improvement scenarios current.
The successive theses will provide FoM with the opportunity to update its improvement areas and identify new actions that can be implemented. In this manner FoM receives fresh input to the growth and improvement plan, making progress towards organizational transformation. Each thesis provides the opportunity to solve key systemic issues and gain from working with world class experts in each technical and management field from MIT.
203
Gen. 1
10 Selected Work Areas
Actions
I

This approach to improving the PD activities of FoM helps ensure that we have both a master plan and a process to enhance it. In many ways, the act of creating and updating a plan can be more valuable than only following a baseline plan. In our case, we have set a strategic direction and we can now update our plan to achieve our vision in an organized and aligned manner.
The topics and selected areas for work during each of the thesis cycles have been defined to avoid excessive overlap among the thesis. With this purpose, the overall problem has been divided into four chunks that will cover the whole of the PD process as presented in Figure 11-6.
Figure 11-6 Designated phases for theses development
These four phases are meant to become the general work flow for each successive thesis, but not limit the specific topic or approach to the problem. A way to visualize these areas is as 'sandboxes' (Browning, Fricke, & Negele, 2006). Within them, each student/employee may build whatever castle they can imagine, limited only by the properties of the sand (time, the target organization and PDS goals). The expectation is that every student will explore their topic in depth, provide insight to that phase of PD, and present the best approach to the problem at hand that they can.
1. Validation and Development 1.1 Robust delivery of customer expectations 1.2 Increased use of analytic tools 1.3 Reduce validation times 1.4 Requirements System 2. Design 2.1 Efficient design iteration process 2.2 Improved design practices 2.3 Lessons learned system 3. Launch 3.1 Manufacturing integration to PD as a process 3.2 Design for manufacturability 3.3 Coordination of launch process 4. Define 4.1 Customer needs and engineering involvement 4.2 Product architecture development 4.3 Commonality and platform leverage
Table 11-3 Initial list of possible topic areas for future theses
Alignment and links among the theses must be created to allow FoM to achieve its future vision. Discussions leading to the development of the PDS architecture surfaced areas of opportunity in each of the four phases for future theses. These opportunity areas have been summarized in Table 11-3 and provide some initial ideas of problems that could be research in each phase. However, other better focus areas and opportunities maybe found during the detailed work in each phase as
204

the long term plan moves forward. A condensed review of the potential elements available for future theses topics alignment is presented in Table 11-4.
# Figure Name Purpose Define the architecture for the
.etfr the PDS FoM PD organization of the F-10.19 Architecture future. Identifies the concept
Architecture and form for the system. Key alignment element for theses
Links work areas for FoM to the MapofthePDS concept and form of the PDS Map of the PDS Architecture. Allows for work
T-12.1 :: ,":.. i Architecture to WorkArchitecture to Work and implementation at FoM. I ........... Areas
7.. .. u.um... Key alignment element forS. C... rf... . x 7 S ,, nxh h theses
Clarify the flow of elements Conceptual Flow Model - from PDS architecture to
F-12.1 From PDS Concept to the implementation. (PDS Organization Architecture->Work areas-
>Actions->FoM
Describe the constant FoM Improvement improvement of work areas,PF-12.2 J Process and the static nature of the PDS
marchitecture and FoM Vision
Allow management of theses F-12.4 FoM Linked Theses Plan and visualization of the linked
thesis concept
Identify the role and value of theses towards improving theF-12.5 FoM Improvement FoM improvement process. Key
:Process alignment element for theses
Opportunity Areas per Phase
List areas of opportunity surfaced during the development of the PDS architecture
Table 11-4 Alignment elements for future theses
205

Interfaces are normally the most difficult areas to manage and the most important. For the linked theses, Table 11-4 attempts to provide some guidance to understanding the interfaces identified. Key to understanding the detail of these interfaces and managing them is the 'Work area to Concept' [Table 11-1] at the beginning of the chapter.
Evolution of the PDS architecture and the development of further implementation actions is the keystone to enabling the transformation of FoM. The plan outlined in this chapter helps us work toward finding solutions to systemic problems and ensure that we reap the most value from FoM's educational investments. By ensuring that leadership, a clear direction and focus on process are all constantly maintained we increase the probability of success for FoM's organizational change effort.
11.4 Guidelines for Implementing and Evolving the PDS Architecture
Driving organizational change in Mexico and improving its PD activities relies on lessons from past experiences. Organizational change programs and, in particular, efforts to improve PD organizations have been plentiful. Scholars and researchers have looked into some of these efforts to achieve change and have produced guidelines of best practices for other companies. FoM can benefit form these past experiences and avoid making the same mistakes.
We have identified that the guidelines from past organizational change efforts apply to three large areas: the 'program', the 'work area' or the 'action'.
In his review of many successful organizational change efforts in the US, Shapiro (Fall 1984, p. 167) identified five qualities that all the successful organizational change programs had in common. Table 11-5 lists these qualities and cross-references them to one of three organizational change phases: Development of the PDS Architecture, Implementation of the PDS Architecture or Evolution of the PDS Architecture.
Qualities of Successful Change Program Organizational Change Phase 1. The programs were tailored to the particular - Development
location and people - Evolution 2. Change was presented in a form that promises - Implementation
rewards, not threatens 3. Built on the assumption that management does - Development
not have monopoly on imagination or common - Implementation sense
4. Bring people that are affected into the planning - Implementation process; and send a signal that management - Evolution recognizes that they may be under challenging people and are willing to experiment
5. People are complimented - Implementation Table 11-5 Guidelines for successful organizational change programs (modified form (Shapiro, Fall 1984))
In their article on the Toyotas product development system, Dehoff and Loehr (Dehoff & Loehr, Innovation Agility, 2007) describe 5 steps to begin deploying organizational change in the pursuit of
206

improved product development. These five steps are well suited to guide the selection and prioritization of 'work areas' for FoM. Table 11-6 lists these five steps and references them to the selected initial work areas.
Work Areas for Successful Deployment of FoM Initial Work Area Organizational Change
1. Rethink goals - Incentive System - Continuous Improvement
2. Develop long term talent - Hands on Engineering - Incentive system
3. Leverage the function-product tension - Process Discipline 4. Reclaim knowledge - Continuous Improvement
- Customer Focus - Design Philosophy
5. Instill a flexible work ethic - Culture - Incentive System - Leadership and Teamwork - Hands on Engineering - Eliminate Information Flow Inhibitors - Tool Usage
Table 11-6 Guidelines for successful deployment of organizational change (modified form (Dehoff & Loehr, Innovation Agility, 2007))
Excellent guidelines for implementation of organizational change actions in product development are given by Browning. For these we have cross-referenced them to the 6 stage process for implementation of change actions described in Section 12.2 (Plan->Conceptualize->Design->Test-> Implement->Check).
Guidelines for Organizational Change Actions Implementation Process Step 1. Starting small. Even though the nature of the - Test
changes sought is of a core structural / architectural kind, it is still important to prove out at a smaller scale that allows for the refinement and improvement of the proposal.
2. Reprioritize and reallocate resources. Instead of -Implement searching for additional resources the reprioritization of them is an alternative that is always useful.
3. Admonition to view the proposals as hypothesis. - Plan The input from all parties involved can be of more - Conceptualize value to the proposal than secluding the input to a - Design select few.
4. Create incentive for sharing knowledge, - Plan collaborating and improving. Collaboration is never - Conceptualize
207

trivial and personal agendas have a heavy impact on - Design the actual collaboration - Implement
- Test - Check
5. Executive support. Required for the implementation - Plan and long term success of initiative at all levels in the - Implement product development activity. - Check
Table 11-7 Guidelines for successful organizational change actions (extensively modified form (Browning, Fricke, & Negele, 2006))
The guidelines for the program, the work areas and the actions present a wealth of knowledge for FoM. In addition to this, they provide support to the PDS architecture and the implementation and evolution elements selected by providing a good match between the guidelines and our own assumptions and conclusions.
Last but not least, Shapiro provides advice to all those involved in the change process that is invaluable.
The worst communication practice of all is to say nothing when changes that affect people are taking place. (Shapiro, Fall 1984)
11.5 Key Takeaways - Implementing and Evolving the PDS
Implementation, evolution and management of organizational change as proposed in this chapter requires a team effort and commitment to see it through. The existence of the PDS architecture for FoM helps guide this process and has proven to be invaluable knowledge in developing the future actions necessary. Change, as presented here, requires a combination of elements to occur and it is through comparing our approach to guidelines given by other authors that we find that our thought process has been sound.
From this chapter we find five key takeaways that are general to all organizational change efforts.
1. The value of formulating and using hypothesis
Employing hypotheses to clarify the use of theses and the SDM program as a way to solve systemic issues has helped clarify their role. Definition of a hypothesis in situations like this enables clearer understanding of the expected result and facilitates their management.
2. The architecture to work areas translation matrix
Relating abstract concepts from the architecture to work areas has been a major break through. This allows the organization to participate in the improvement process with greater ease and makes the architecture real.
208

3. Existence of three levels of organizational change
Work to bring the architecture down to a workable level made the existence of three distinct levels for organizational change apparent. These three levels allow for change programs that provide direction yet remain flexible. The existence of these three levels is supported by the different approaches authors use when providing guidelines for organizational change. The three levels are presented in Table 11-8 with suggestions for their use and minimum interval between changes.
Organizational Change Level Main Function Min. Interval between changes 1) Program Provide Direction 2 years 2) Work area Structural Evolution 1 year 3) Action Create Flexibility 3 months
Tabie 11- Three levels of organizational change
4. PDS Architecture as a central element of organizational change
The PDS architecture was key in providing the framework to create the organizational change plan. Ability to develop an architecture for what the organization should be in the future has to this day proved valuable for FoM. The concept for the system helps convey all aspects of the organization of the future with little effort.
5. Affinity of elements of concept or character and guidelines for work areas
Developing guidelines for the work-areas demonstrated that elements from the PDS concept were better suited as guidelines than the principles that were selected for the elements of form. This is an important finding as it validates our selection of work-areas by creating a clean path between the organizations concept and the areas we will work on today.
A recommendation to create a systems engineering organization remains strong and may become critical to the long-term viability of the organization. Follow through on the improvement actions and work on other high complexity, multidisciplinary problems will create urgent demand for this group.
The work in this chapter has taken the first steps toward implementing and evolving the PDS architecture. Definition has been given to some of the key interfaces that will take place to help maintain coherence moving forward. Special effort has been put into creating adequate interfaces between the PDS architecture and the future theses to ensure that FoM can mange this initiative. Success with this initiative is seen as possible, yet much work remains before the larger fruits are collected.
209

12 Conclusions
Product Development: The set of multifunctional information transformation activities beginning with the perception of a market opportunity (customer need) and ending in the delivery of a finished design, which enables production, sale, delivery and service of a product.6
Product development is key to the success of companies involved in commercial activities, and even though this fact is widely accepted, few companies have truly mastered the development of new products. Within the automotive industry the development of new products acquires an even greater importance because of factors such as the hyper-competitive nature of the automotive business, the small sales margins, relative high cost of automobiles and the intrinsic technical complexity of the product. In aggregate, these factors make automotive product development highly competitive and thus the perfect setting for designing an improved product development system.
Improving product development requires us to determine how the many technical and social interactions that take place during the development of process will work. In this regard we have seen that using a systems engineering approach to analyze and design an improved product development system is a conducive to positive results.
When we look at product development from a systems engineering point of view and work on designing an improved PDS (product development system) it becomes key to understand what the PDS is and how this abstraction relates to the real world. In companies, the PDS is normally found constituted in what is called the PDO (product development organization). Conceptualizing the PDS is critical to enabling us to improve product development in a systematic way, as it ensures we think about all the elements - tangible and intangible - that affect the performance of new product development. The following definitions summarize these concepts.
Product Development System (PDS): the aggregate of the essential elements of structure (functional elements, links and arrangement) and character or concept (values, principles, operating style) as defined by the system architecture that determine what, when, where, who and how product development is executed.
Product Development Organization (PDO): the entity within a company responsible of developing new products that contains all the elements and resources for this task.
Relationship between PDS and PDO: The Product Development Organization (PDO) is the embodiment of the Product Development System (PDS).
6 Extensively modified form the definition of product development provided by Ulrich and Eppinger (2004)
210

The key to designing an improved PDS lies in our ability to define the system architecture, which is consequently also critical to the success of the PDO. The architecture of the PDS is born as an answer to the questions of how to deliver on the system goal and requirements under the specific elements of context for the PDS under consideration. An important conclusion we can make from this description of the PDS architecture is that each PDS will necessarily drive a unique architecture because of changes in the context of the system, its goals or requirements. This conclusion is significant, as it transcends the PDS and highlights the fact that each PDO must develop and understand what their architecture - structure and concept - is, if they are to truly improve how they execute product development.
PDS Architecture: the context-specific operating framework provided by the structure and concept of the PDS that determines its value creation proposition.7
The architecture of PDS has both general and application-specific elements. Developing the specific elements requires a case example that provides the necessary details; in our case we have chosen the product development organization of FoM (Ford of Mexico) as our focus. Context-specific attributes such as local culture, geographic location and organizational size of FoM played a key role in the determining the architecture of the FoM PDS. The impact of the context-specific elements to the architecture of a PDS was then further confirmed through analysis of other world class product development organizations.
Structural Element Key Determinant Product Product Architecture Process Logic of the Product Development Process People Organizational Structure Goals Metrics and Targets
Table 12-1 Key determinants for each of the structural elements of the product development system
The structure of the PDS was found to have five generic systems as proposed by Browning et al. (2006) - product, process, people, tools and goals. At the generic level, key determinants of the inner structure for product, process, people and goals were identified [Table 12-1]. The key determinants constitute critical aspects that each of the structural systems contributes towards defining the architecture of the PDS. In-depth exploration of each structural system is provided in chapters 5 through 7.
The detailed definition of each of the structural systems is a task that never ends for the PDO, but one that must be guided to ensure proper alignment amongst all elements. For the PDS of FoM a series of guidelines were developed to help achieve this objective and are presented in detail in chapter 9. Identifying the set of guidelines for each system is done as an iterative process that
7 Definition of 'PDS Architecture' makes use of definitions of architecture as provided by Crawley (2006) and Aguirre Esponda (2008)
211

requires in-depth knowledge of the system and guided by a gradual understanding of the emerging concept for the PDS.
The concept - or character - of the PDS is the element of the architecture that was found to have the greatest effect over the PDS. The concept is, however, difficult to fully understand and distil in systems that are heavily human and social, such as the PDS. What is the concept within the PDS later becomes what is called the 'culture' of an organization, determining how the organization works at all levels. This is critical to the success of a PDO because it will impact each and every move the organization makes. However, it is the most difficult aspect to change in an organization and the one that is most difficult to design. One of the reasons working with the concept of the PDS is so difficult is because its implementation and resulting effects may take a long time to truly permeate throughout the organization. Because of this, it is important to find a concept for the PDS and then implement it with care, allowing for evolution and true acceptance within the organization.
For the Ford of Mexico PDS, one overarching idea - uninterrupted flow of information - and four elements of character - excellent communication, flexibility, decision process and perfect execution - were chosen to help define the concept of the system.
Concept for the PDS of FoM: To create an uninterrupted flow of information from customer needs to finished design by mastering excellent communication, flexibility to adapt to changing requirements, robust engineering decisions and perfect execution of all activities.
The aggregate of the elements of structure and concept forms the architecture for the PDS of FoM and has been summarized visually and verbally in chapter 9. An important lesson from having designed the architecture for the FoM PDS is that it must be a 'social' and 'team' activity if it is to have any success or impact. The people in a PDO are one of the systems that make up the structure of the PDS and are the owners of the character. Failure to include the organization during the design of a PDS will mean that the finished design may well be severely out of context.
Architecture of the FoM PDS: Aligned FoM specific goals, people, process, tools and product, as defined by the system guidelines that allow the FoM PDO to deliver an uninterrupted flow of information from customer needs to finished design by mastering excellent communication, flexibility to adapt to changing requirements, robust engineering decisions and perfect execution of all activities.
Although not presented in detail in these conclusions, the system guidelines for the PDS are essential to provide substance to the architecture. They constitute the solution to some of the key problems within the structural systems and their interfaces; knowledge that must be integrated to make the architecture valuable. Designing the architecture for a PDS requires knowledge of the elements that constitute the system and their interfaces. This knowledge is the basis for generating guidelines for the PDS that are applicable to the corresponding PDO.
212

The implementation of the architecture for a PDS constitutes, in itself, an important task. It was found that the framework and information that is contained in the architecture for the PDS is not intuitively applicable to the FoM PDO - an intermediate step between architecture and implementation is necessary. It is proposed that a method to achieve this is by using the PDS architecture to find work areas within the PDO and then define actions that can begin to be taken toward implementing the architecture. In this manner, the high-level and abstract nature of the architecture becomes implementable and the challenges the organization must overcome to achieve the desired end state can be identified and tackled.
The improvements required to complete the PDO can not be tackled in a single blow; rather the coordinated work of many people in the organization is necessary. It is because of this that having an architecture for the PDS becomes valuable, as it provides a reference framework for all work. At FoM, the objective is to create the best automotive PDO in the world, and to this means the general problem has been divided in four complementary parts - define, design, validate and launch. These four elements parcel product development into the four main process constituents and provide a way to systematically pursue the detailed design - improvement - of the FoM PDO. In this case, it has been decided that much of the ground work to design the PDO will be done by students at MIT. Some of this work has already begun, and it has been concluded that having the PDS architecture has been a key aid in coordinating these efforts.
With the conclusions and summary of the work developed in this thesis, we can review our initial hypotheses. In summary, the thesis did conduct work regarding each of these three hypotheses and reaches conclusions regarding two of them. The third hypothesis is addressed through an initial assessment, but more time must pass for comprehensive evaluation and conclusion.
Hypothesis 1: It is possible to consider product development a system, and therefore design as a system by identifying needs, creating architecture, developing the detailed design, implementing the design and selling the final product
Based on the work done throughout this thesis we can conclude that product development can be considered and dealt with as a system, and that its design can make use of systems engineering methods as guidance. The positive effects that FoM has registered up to date as a consequence of generating an architecture for the Ford of Mexico Product Development Organization give us confidence that there is value in this approach to improving product development.
Hypothesis 2: Problems with the architecture of the product development system gravely affect the outcome of product development, independently of the quality and individual potential of the people, the process, the tools or the product that at hand
As with all systems, the architecture of the PDS has a direct effect on the effectiveness of the organization in developing new products. The ability to understand and create an architecture for an organization is one of the key enablers to achieve true competitiveness;
213

Toyota is a fantastic example of this ability, achieving purposeful alignment of all its resources using 'the Toyota Way' - the how.
Hypothesis 3: If we consider product development a system; its design and implementation can be done by creating the architecture and disaggregating the problem into complementary parts
At this point, this thesis has not been able to conclusively determine if, for the design of a product development system, one can, in advance, clearly define all the complimentary parts needed to deliver the full system. However, guidelines have been established to enable the problem to be fragmented temporally and still allow for re-integration.
As part of the work to design a PDS, nine principles regarding what makes good product development have emerged and are embedded in the guidelines for the architecture of the FoM PDS. These principles are, in some cases, matched by some of those found in two comprehensive sets of principles by previous authors8. This fact increases our confidence in our findings, conclusions and the architecture that has been designed for FoM.
* Have a design philosophy * Do hands on engineering * Engage in continuous improvement * Develop flexible capabilities * Develop excellent communication abilities * Approach product development holistically * Focus on the customer * Demand process discipline * Respect people
Designing the PDS and its architecture is a task that all PDOs have done in one way or another. Some have done it consciously, by dedicating resources to this task, while others have done it unconsciously along the way. However, the best PDOs 9 analyzed for this thesis demonstrate that they have an internal alignment among all elements and a particular way of working that enables them to be the best in class. These two elements - alignment and how they work - are the focus and purpose of the PDS architecture. Therefore, using a systems engineering approach for improving product development can allow PDOs to systematically work toward becoming their best in class.
8 The lists of principles can be found in the Chapter one
9 Toyota, Ford of Europe, Nascar Race Team, Porsche
214

As a final note, due to the very broad scope of this thesis, many important conclusions for the subtopics and systems that constitute the PDS architecture have been omitted from these final conclusions. Therefore, an effort has been made to provide 'Key Takeaways' in a standardized format for all the chapters in this thesis. These 'Key Takeaway' sections can be read as an extended set of conclusions if there is additional interest in any of the individual subjects.
215

THIS PAGE INTENTIONALLY LEFT BLANK
216

Bibliography
Adler, P. S., Goldoftas, B., & Levine, D. I. (1999). Flexibility Versus Efficiency. Organizational Science, 43-67.
Aguirre Esponda, G. J. (2008, January 11). Design and Architecture of Complex Systems. (A. A. Granados, Interviewer)
Aguirre, A., Endo, T., Espinosa, F., Sacka, M., & Soto, L. (2006). A Case Study of Product Development -MIT. Cambridge, MA.
Allen, T. J. (2007). Architecture and Communication among Product Development Engineers. California Management Review, 49 (2), 23-41.
Allen, T. J. (2006, February). Organizing for Product Development - Lecture at MIT.
Allen, T. J., & Henn, G. W. (2007). The Organization and Architecture of Innovation. Burlington, MA: Butterworth-Heinemann and Architectural Press, Elsevier.
Allen, T. J., Lee, D., & Tushman, M. (1980). R&D performance as a function of internal communication, project management, and the nature of work. IEEE Transactions on Engineering Management (27), 2-12.
Allen, T., & Henn, G. (2007). The Organization and Architecture of Innovation. Burlington, MA: Butterworth-Heinemann.
Autopartes, I. N. (n.d.). INA. Retrieved 01 15, 2008, from INA: http://www.ina.com.mx/
BBC. (n.d.). Globalization - The Car Industry. Retrieved 01 16, 2008, from BBC News - In Depth: http://news.bbc.co.uk/2/shared/spl/hi/guides/457000/457029/htm /defa u lt.stm
Bongaerts. (1998). Concepts for Holonic Manufacturing.
Bongaerts. (1998). Integration of Scheduling and Control in Holonic Manufacturing Systems. Thesis PMA/K.U.Leuven.
Bromage, M. C. (1970). Defensive Writing. California Mangement Review, 45-50.
Brown, S. L., & Eisenhardt, K. M. (1995). Product Development: Past Research, Present Findings, and Future Directions. Management Review, 20 (2), 343-378.
Browning, T. R., Fricke, E., & Negele, H. (2006). Key Concepts in Modeling Product Development Processes. 9 (2).
Carbodydesign.com. (n.d.). History of the Automobile Chassis. Retrieved 01 20, 2008, from http://www.carbodydesign.com/articles/2005-04-13-chassis-history/chassis-history-7.html
217

Casadesus-Masanell, R. (2006). Competing with Business Models - HBS Fall 2006 Lecture Series. Cambridge, MA, US.
Clark, K. R., & Fujimoto, T. (1991). Product Development Performance - Strategy, Organization and Managment in the World Auto Industry. United States: Harvard Business School.
Cohen, M. A., Eliashber, E., & Ho, T.-H. (1996). New Product Development: the Performance and time to Market Trade off. Mangement Science, 173-186.
Collins, J. (2001). Good to Great: Why Some Companies Make the Leap and Others Don't. New York: Harper Collins Publishers.
Cossick, K., Byrd, T., & Zmud, R. (1992). A synthesis of research on requirements analysis and knowledge acquisition techniques. MIS Quarterly (16), 117-139.
Crawley, E. (2006). MIT - Systems Architecture Lectures 2006. Cambridge, MA, United States.
de Weck, 0. (2006). Lecture - Thesis Seminar MIT.
de Weck, O. (Fall 2006). System Project Mangement Lectures - MIT - Fall 2006. MA, United States: MIT.
Deboer, J. (2007, 11 15). Director - Sundberg Ferar. (A. Aguirre, Interviewer)
Dehoff, K., & Loehr, J. (2007). Innovation Agility. Strategy and Business, 3-4.
Dehoff, K., & Loehr, J. (2007). Innovation Agility. strategy+business (47).
Detroit Diesel. (n.d.). http://www.detroitdiesel.com/public/brochures/6SA591.pdf. Retrieved 01 17, 2008, from The ABC's of Exhaust Gas Recirculation (EGR): http://www.detroitdiesel.com/public/brochures/6SA591.pdf
DieselNet. (n.d.). DieselNet. Retrieved 01 17, 2008, from Emissions Standards: USA: Heavy Duty Truck and Bus Engines: http://www.dieselnet.com/standards/us/hd.html#y2007
Dori, P. (2005). OPM. Retrieved 11 8, 2007, from OPM Official Website: http://dori2.technion.ac.il/opm/methodology/default.asp?up=indir&sec=5
Dunbar, R. L., & Starbuck, W. H. (2006). Learning to Design Organizations and Learning from Designing Them. Organizational Science, 17 (2), 171-177.
Edmondson, A., Bohmer, R., & Pisano, G. (2001, October). Speeding Up Team Learning. Harvard Business Review, 125-132.
Endo, T. (2008, 01 31). (A. Aguirre, Interviewer)
Eppinger, S. D. (January 2001). Innovation at the Speed of Innovation. Harvard Business Review.
218

Evans, D. S., & Webster, K. L. (2007). Desinging the right product offerings. MIT Sloan Mangment Review, 44-50.
Farrell, D., Laboissiesre, M. A., & Rosenfeld, J. (2005). Sizing the emerging global labor market. The McKinsey Quarterly (3).
Fine, C. H., & Whitney, D. E. (1996). Is the Make-Buy Decision Process a Core Competence? Sloan WP # 3875.
Fischer, B., & Boynton, A. (2005, July-August). Virtuoso Teams. Harvard Business Review, 116-123.
Flow Grid Consortium. (n.d.). Retrieved January 17, 2008, from Flow Grid Project: http://www.unizar.es/flowgrid/exhaust.htm
Follet, M. P. (1949). Lectures in Business Organization. Mangement Publications Trust.
Ford Motor Company. (2004). Ford Motor Company - Sustainability report 2004/05 - Economic Contribution of the Automotive Industry. Retrieved 08 12, 2007, from http://www.ford.com/en/company/about/sustainability/report/comContribution.htm
Ford Motor Company. (n.d.). Ford Racing: TeamFord Racing News. (Ford Motor Company) Retrieved 08 27, 2007, from http://www.fordracing.com/news/detail/?article=28440
Ford Motor Company. (2006). Sustainability Report 2006/07.
Fricke, E. (2007, November). (A. Aguirre, Interviewer)
Fricke, E., Gebhard, B., Negele, H., & Igenbergs, E. (2000). Coping with Changes: Causes, Findings and Strategies. Systems Engineering, 169-179.
Gladwell, M. (2002). The Tipping Point. First Back Bay.
Griffin, A., & Hauser, J. R. (1992). Patterns of Communication Among Marketing, Engineering and Manufacturing - A Comparison Between two new Product Teams. Management Science , 38 (3), 360-372.
Hale, P. (2007, 12 14). Director of the System Design and Management Program at MIT. (A. Aguirre, Interviewer)
Hall, J. (1973). Communication Revisited. California Management Review, XV (3), 56-67.
Hauser, J. R. (2000). Metrics Thermostat.
Hauser, J. R., & Clausing, D. P. (1988). The House of Quality. Harvard Business Review, 66 (3), 63-73.
Hess, E. D., & Kazanjian, R. K. (2006). The Search for Organic Growth. Cambridge: Cambridge University Press.
219

Huddle, F. P. (Winter 1966). Coordination. California Mangement Review, 9-16.
Katz, R. (1982). The effects of group longevity on project communication and performance. Administrative Science Quarterly (27), 81-104.
Krishnan, V., & Ulrich, K. T. (2001, January). Product Development Decisions: A review of the Literature. Mangment Science, 1-21.
Kupczewski, C. D. (2005). Leon Product Development for the Automotive Niche Vehicle Market Place. Cambridge, MA: MIT.
Liker, J. (2003). The Toyota Way. New York: McGraw Hill.
Loch, C. H., & Terwiesch, C. (1998). Communication and Uncertainty in Concurrent Engineering. Management Science, 44 (8), 1032-1048.
Magretta, J. (2002, May). Why Business Models Matter. Harvard Business Review, 86-92.
Maier, A. M., Eckert, C. M., & Clarkson, P. J. (2006). Identfying requirements for communication support: A maturity grid-inspired approach. Expert Systems with Applications (31), 663-672.
Maier, M. W., & Rechtin, E. (2002). The Art of Systems Architecting. CRC Press.
Malone, T. W., Crowston, K., & Pentland, B. (1999). Tools for Inventing Organizations: Toward a Handbook of Organizational Processes. Management Science, 45 (3).
McAliden, S., Hill, K., & Swiecki, B. (Fall 2003). Economic Contribution of the Automotive Industry to the U.S. Economy - An Update. Center for Automotive Research.
McManus, H. (2004). Product Development Value Stream Analysis and Mapping Manual (PDVSM). Cambridge, MA: MIT.
Mexico, S. d. (n.d.). Secretary of Economy - Mexico. Retrieved 01 15, 2008, from Secretary of Economy - Agreements and Negotiations: http://www.economia.gob.mx/?P=2113
Morgan, J. (2002). High performance Product Development: A Systems Approach to a Lean Product Development Process. Ann Arbour, MI: UMI Dissertation Services.
Morgan, J. M., & Liker, J. K. (2006). The Toyota Product Development System. New York: Productivity Press.
Object Process Methodology. (2006). objectprocess.org. Retrieved 10 30, 2007, from http://www.objectprocess.com
Ogawa, S. (2006). Reducing the Risks of New Product Development. 47 (2).
Pahl, G., & Beitz, W. (2007). Engineering Design. Springer.
220

Pajerek, L. (2000). Processes and Organizations as Systems: When the Processors are People and not Pentiums. 3 (2).
P4rez Oyamburu, M. (2007, 08). FoM Product Development. (A. Aguirre Granados, Interviewer)
Perez, M. (2007, June). FoM Gorwth . (A. Aguirre, Interviewer)
Porter, M. E. (1979, March-April). How Competitive Forces Shape Strategy. Harvard Business Review ,137-145.
Reinertsen, D. (1999). Lean Thinking isn't so Simple. 48.
Repenning, N. P., & Sterman, J. D. (2001). Nobody Ever Gets Credit for Fixing Problems that Never Happened: Creating and Sustaining Process Improvement. California Mangement Review, 43 (4).
Schaffer, R., & Thompson, H. (1992, Jan/Feb). Successful Change Programs Begin with Results. Harvard Business Review, 80-89.
Schein, E. H. (Fall 1996). Three Cultures of Mangement: The Key to Organizational Learning. Sloan Management Review, 9-19.
Shapiro, I. S. (Fall 1984). Executive Forum: Manegerial Communication: The view from Inside. California Mangement Review, 157-172.
Shook, J., & Rother, M. (1998). Learning to See. Burlington, MA: The lean enterprise institute.
Simchi-Levi, D. (2002). Designing and managing the supply chain - Concepts Strategies and Case Studies. McGraw Hill Companies.
Sobek, K. (1997). Principles that shape product development systems: a Toyota-Chrysler comparison. Ann Arbor, MI: UMI.
Sosa, M. E., Eppinger, S. D., & Rowles, C. M. (2007, November). Are Your Engineers Talking to One Another When They Should? Harvard Business Review, 133-142.
Sterman, J. D., Repenning, N. P., & Kofman, F. (1997). Unanticipated Side Effects of Successful QUality Programs: Exploring a Paradox of Organizational Improvement. Management Science, 43 (4), 503-521.
Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems Engineering Coping with Complexity. Hockley: Prentice Hall Europe.
Szulanski, G. (1996). Exploring internal stickiness: impediments to the transfer of best practice within the firm. Strategic Management Journal, 17, Winter Special Issue, 27-43.
221

Takikonda, M., & Montoya-Weiss, M. M. (January 2001). Inegrating Operations and Marketing Prespectives of Product Development Innovation: The Influence of Organizational Process Factors and Capabilities on Development Process. Mangement Science, 47 (1), 151-172.
Tatikonda, M. V., & Rosenthal, S. R. (2000). Successful executuion of product developemnt projects: Balancing firmness and flexibility in the innovation process. 18.
The Design Structure Matrix Website. (n.d.). The Design Structure Matrix Website - DSM Tutorial. Retrieved 01 21, 2008, from http://www.dsmweb.org/content/view/21/26/
Tushman, M. L., & Katz, R. (1980). External Communication and project performance: An investigation into the Role of Gate Keepers. Management Science, 26 (11), 1017-1085.
U.S.Department of Labor Bureau of Labor Statistics. (n.d.). Consumer Expenditure Survey. Retrieved 01 20, 2008, from http://www.bls.gov/cex/
Ulrich, K. T., & Eppinger, S. D. (2004). Product Design and Development. New York: McGraw- Hill/Irwin.
Ulrich, Karl T.; Eppinger, Steven D. (2004). Product Design and Development (3rd ed.). McGraw-Hill.
Uminger, G. (2003, May 6). The University of Michigan Lean Conference. Presentation Slide.
Varadarajan, R. (2007, March). Think Small. MITSloan Business Review.
Watanabe, K., Thomas A. Stewart, T. A., & Raman, A. P. (2007, July 01). Lessons from Toyota's Long Drive: A Conversation with Katsuaki Watanabe. Harvard Business Review.
Womack, J. P., Jones, D. T., & Roos, D. (1991). The Machine that Changed the World - The Story of Lean Production. New York: Rawson Associates.
222

THIS PAGE INTENTIONALLY LEFT BLANK
223

THIS PAGE INTENTIONALLY LEFT BLANK
224

THIS PAGE INTENTIONALLY LEFT BLANK
225