Leveraging the Capacity of Human Capital in a Product
Development Organization
by
Rodolfo Reyes Luna
B.S. Electromechanical Engineering with a minor in Advanced Manufacturing, 2006
Instituto Tecnol6gico de Toluca, Mexico
SUBMITTED TO THE SYSTEM DESIGN AND MANAGEMENT PROGRAM
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF
Masters of Science in Engineering and Management
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
February 2015.
2015 Rodolfo Reyes Luna. All rights reserved.
I
Z
C=)
CL)
C!:
c
wo
WM
T $O
L
g
_
C/,
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 in any medium now known or hereafter created.
Signature redacted
Signature of Author
Rodolfo Reyes Luna
System Design and Management Program
January 5, 2015
Certified by
__Signature
redacted
Steven D. Eppinger
Professor of Management Science and Innovation
Co-Director, MIT System Design and Management Program
MIT Sloan School of Management
h
e
rvisor
Accepted by
Signature redactE A
P;'1?atrick Hale
Director, System Design and Management Program
Massachusetts Institute of Technology
Disclaimer IThe opinions expressed in this thesis are those of the author and do not reflect the
official policy or position of Ford of Mexico or Ford Motor Company.
1
(This page intentionally left blank)
2
Leveraging the Capacity of Human Capital in a Product
Development Organization
by
Rodolfo Reyes Luna
Submitted to the System Design and Management Program
on January 5, 2015 in Partial Fulfillment of the Requirements for the Degree of
Masters of Science in Engineering and Management
Abstract
This research has as fundamental purpose, the generation of strategies for the product
development organization in Ford of Mexico; the goal is to increase the capability of the
workforce for the development of future work streams. In this thesis, a network model for
organizational architectures referred as organizational design structure matrix is used to identify
the main interactions among the project teams; this interaction pattern is compared to product
interfaces captured in a product DSM model. A case study from Ford Motor Company is
utilized; the development is narrowed to the analysis of the front end system of a new CD
platform vehicle during the main stages of the product development process.
To set up a context for this thesis, I elaborate the product development process from Ford and
describe the main design challenges from the case study. In this thesis, I also explain the role that
communication plays in an organization due to team geographic location and categories within
the organization. DSM concepts and methods are explained to converge further in the application
of the product development organization case study.
I start the research with the creation of the product DSM for the front end system team through
data collection, and interviews with the core engineering group at the company; surrogate data
from current production CD vehicles was analyzed. I survey the Ford front end system team to
understand the frequency and level of interaction among component teams during the
development of the project. Technical maturity level of each team member is collected as well.
Additional data from the program management team is acquired to cross reference project team
performance with organizational communication. I compare the data set collected with the
product architecture DSM to determine mismatches in the organization interactions. In addition,
a series of clustering analyses are also compared to improve the team design structure matrix;
these results allow us to convey strategies and recommendations to Ford of Mexico organization,
to ultimately enhance the product development organization capabilities.
Thesis Supervisor: Steven D. Eppinger
Title: Professor of Management Science and Innovation
Co-Director, MIT System Design and Management Program
MIT Sloan School of Management
3
Acknowledgments
The opportunity to join to the MIT has been a groundbreaking in my life, it represents one of the
biggest achievements I have ever had. Walking this journey all the way a long until the
completion of my thesis has been a privilege; I could not have accomplished it without the
support of many people, especially to those who have been around me since the beginning of this
program:
Firstly, my lovely wife Karen and my sweet daughter Sofia who have sacrificed a lot in
order to make my dream come true. I am grateful and deeply in debt for all the love,
support and consideration that you have gave to me. FernanditaI am excited for your
arrival. You all are the beat of my heart.
My mother, Fernanda, whom always looked for my welfare despite the distance, for the
encouragement and devotions you put on me, I love you.
My father, Rodolfo, for being my advisor of life, whom gave all his effort and hard work
for my success, you are my model to follow.
My brother, Ricardo, for your unconditional support during the toughest times, you are
my best friend.
Alejandro Ayala, whom believed on me, thanks for pushing me to pursue this masters, it
has been the best opportunity I have ever had for my professional career.
Marcos Perez, whom gave the opportunity to make my masters at the MIT.
Kian Tan, for your guidance, support and friendship during my formation.
Mark Garascia, for the flexibility provided during these two years, for every single
encouraging word and for the great support during adversity.
Shawn Morgans, for your guidance, advice and coaching in the company.
FoM PD team, for the willingness to help in the development of this research.
SDM'13 peers, for the valuable comments and ideas provided to me when discussing our
thesis projects. Especially to Juan Quezada, for the advice and the endless conversations
we had related to engineering and life. And to Jonathan Cuata for the commitment and
great team work during this journey, I won't forget the number of hours we spent on our
school projects. Thank you both for your friendship and the relationship we established
with our families.
To all SDM Faculty and staff, you have provided the best resources to succeed.
4
Dr. Steven D. Eppinger, whom provided the best advice ever to complete this research, I
would like to thank you for the guidance, time and knowledge shared to materialize my
master degree thesis. It has been a great experience to work close to an eminence in the
DSM world.
Last, but not least, thank you all of my relatives and friends that were always there.
Thank you.
01
5
(This page intentionally left blank)
6
Table of Content
A bstract...........................................................................................................................................
A cknow ledgm ents ..........................................................................................................................
Table of Content .............................................................................................................................
List of Figures.................................................................................................................................9
List of Tables ................................................................................................................................
11
List of A cronym s ..........................................................................................................................
12
1
2
Introduction............................................................................................................................13
1.1 M otivation..........................................................................................................................14
1.2 Thesis O bjectives and Prem ises......................................................................................
1.3 Research M ethods and Approaches ...............................................................................
16
17
1.4 Thesis Structure .................................................................................................................
18
O rganizational C ase Study: CD -Car Project .................................................................
20
2.1 Vehicle Segment ................................................................................................................
2.2 A utom otive System Decom position ..................................................................................
20
22
2.2.1
2.2.2
3
3
4
7
Product Architecture of the Front End System ..................................................
Subsystem Boundary Diagram ..............................................................................
24
25
2.2.3 Product Module Team .........................................................................................
2.3 Project Size ........................................................................................................................
2.4 Product D evelopm ent Process ........................................................................................
28
29
30
Communication in the Organization and Network Modeling Tool ..............................
35
3.1 Com m unication in the O rganization........................................................................
3.2 Com m unication as Function of the Workplace ......................................................
3.2.1 Functional Organization........................................................................
3.2.2
3.2.3
Project Organization ..............................................................................
M atrix Organization...............................................................................
36
40
41
42
42
3.2.4 Examples of Communication in the Organization.................................43
3.3 V arious Fram ew orks of Com munication..................................................................49
3.3.1 Leadership Perspective ..........................................................................
49
3.3.2 FoM Approach ...........................................................................................
49
3.3.3 Lean Design Principle................................................................................50
3.3.4 Organization in Product Innovation......................................................
52
3.4 Approach and Design Structure M atrix M ethods....................................................
55
3.4.1
Design Structure M atrix D efinition ......................................................
3.4.2
Types of D SM ........................................................................................
59
3.4.2.1 Multi-dimensional Embedded Matrix (MDEM)........................61
57
3.4.3
D SM Process Generation...........................................................................62
3.4.4
3.4.5
Product Architecture D SM A pplication.....................................................64
Clustering Analysis ...............................................................................
66
7
4
Analyzing the CD-Car Front End System Case Study.......................................................69
4.1 Organizational Architecture DSM Model....................................................................69
4.1.1 Organizational DSM Definitions ...............................................................
4.1.2 Application Case: CD-Car Front End System .......................................
4.1.3 D ata Collection Process ........................................................................
4.1.4 Product and Organizational Architecture Models..................................75
4.1.5 Results and Proposed System Team Structures .....................................
4.1.5.1 System Team Structure - Proposal I ....................
4.1.5.2 System Team Structure - Proposal 2....................87
4.1.5.3 System Team Structure - Proposal 3........................................
4.1.5.4 System Team Structure - Proposal 4....................89
5
69
73
74
80
86
88
Conclusions and Recommendations..................................................................................92
5.1 Summary of Results and Conclusions ......................................................................
92
5.2 General Recom m endations ......................................................................................
95
5.2.1 Recommendations for FoM
to Leverage the Capability of Human Capital .......................................
95
.... 98
5.2.2 Recommendations for Further Research......................................
6
B ib liograp hy .........................................................................................................................
100
7
A p p en d ix A ...........................................................................................................................
104
8
List of Figures
Number
Page
Figure 1-1
Figure 1-2
Figure 2-1
Figure 2-2
Figure 2-3
Figure 2-4
Figure 2-5
Figure 2-6
Figure 2-7
Figure 2-8
Figure 2-9
Figure 3-1
Figure 3-2
Figure 3-3
Figure 3-4
Figure 3-5
Figure 3-6
Figure 3-7
Figure 3-8
Lack of Organization DSM in Failure Mode Avoidance Process..............16
Thesis Flow diagram.................................................................................................17
21
Ford Vehicle Segments ............................................................................................
22
Platform Framework ...............................................................................................
23
High Level Vehicle Decomposition........................................................................
24
Front End Subsystem High Level Decomposition..................................................
27
CD-car Front End System Boundary Diagram ........................................................
28
Global PMT Structure ...............................................................................................
29
Program Scalability Framework ..................................................................................
31
Generic Spiral Process ............................................................................................
34
Staged PDP Comparison ..........................................................................................
Body Closures and Stamping Unit Layout................................................................38
39
HubSpot common spaces ........................................................................................
40
Hierarchy and Closed Workplace ............................................................................
43
Various Product Development Organizations.........................................................
44
Skoda automotive assembly plant...........................................................................
a) FoM Building, b) Probability of Communication....................................................45
Low complexity information....................................................................................46
High complexity information....................................................................................47
Figure 3-9 Body Exterior Departmental Organization ...........................................................
47
48
Figure 3-10 Departmental Size and communication .................................................................
Figure 3-11 The Organizational Structure Mirrors the Established Product's Architecture ......... 53
54
Figure 3-12 Design interfaces and team interaction similarity ..................................................
Figure 3-13 B asic D SM exam ple...................................................................................................58
60
Figure 3-14 Decompositional view of different Types of DSMs .............................................
61
Figure 3-15 Multidomain MDM...............................................................................................
Figure 3-16 Multi-dimensional Embedded Matrix....................................................................62
Figure 3-17 Hybrid Car Decompositional View........................................................................64
65
Figure 3-18 Hybrid System Boundary of a Car ........................................................................
Figure 3-19 Hybrid System DSM model.......................................................................................66
Figure 3-20 Clustered Hybrid System DSM model.......................................................................68
71
Figure 4-1 Identification of design and communication interfaces ..........................................
Figure 4-2 Frequency of communication and product dependency nomenclature....................72
73
Figure 4-3 CD-car project team communication network ........................................................
76
Figure 4-4 Front End System Product DSM.............................................................................
Figure 4-5 Team Communication Data Set DSM......................................................................77
Figure 4-6 Original Front End System team structure...............................................................78
Figure 4-7 CD-car project Alignment Matrix...........................................................................
80
Figure 4-8 Front End System team location map ......................................................................
82
Figure 4-9 Leveraged Alignment Matrix ....................................................................................
85
Figure 4-10 Front End System Team Structure - Proposal 1 (4 clusters) ................................. 86
Figure 4-11 Front End System Team Structure - Proposal 2 (3 clusters).................................87
9
RRIRMWP91"--
Figure 4-12 Front End System Team Structure - Proposal 3 (3 clusters and Component
8
In te g ratio n ).................................................................................................................8
Figure 4-13 Front End System Team Structure - Proposal 4 (MDEM 2 clusters)...........89
Figure 4-14 Multiple Clustering Solution Summary .................................................................
91
10
List of Tables
Number
Table
Table
Table
Table
Table
Table
2-1
3-1
3-2
3-3
3-4
4-1
Page
Front End Subsystem Decomposition List ...............................................................
The know-don't know quadrant ..............................................................................
Product Development Performance comparison by regional auto industries .......
Design Dependency Criticality.................................................................................57
Criteria for Successful D SM s...................................................................................
Count of Design and Organization Interfaces ..........................................................
25
50
52
63
81
11
List of Acronyms
3D
AC
CAD
CAE
CT
DC
DSM
EMM
FEM
FMA
FoM
FoMoCo
GOR
HVAC
IR
MDEM
MDM
MIT
MY
NAIAS
NHTSA
OEM
PD
PDP
PI
PMT
SDS
USA
Three-dimensional
Alternating Current
Computer Aided Design
Computer Aided Engineering
Component Teams
Direct Current
Design Structure Matrix
Engineering Matters Meeting
Front End Module
Failure Mode Avoidance
Ford of Mexico
Ford Motor Company
Grill Opening Reinforcement
Heating, Ventilation and Air Conditioning
Input in rows
Multi-dimensional Embedded Matrix
Multidomain Design Matrix
Massachusetts Institute of Technology
Model Year
North American International Autoshow
National Highway Traffic Safety Administration
Original Equipment Manufacturers
Product Development
Product Development Process
Program Integration
Product Module Team
System Design Specification
United States of America
12
Chapter 1 - Introduction
"The journey of a thousand miles begins with one step"
Lao Tzu
Workforce capability within the car manufactures is an important characteristic to successfully
deliver new vehicle designs given the growing market in the auto-industry. The automotive
original equipment manufacturers (OEM) have faced more aggressive challenges to meet not
only customer demands but also new requirements worldwide. More efficient vehicles to
improve fuel economy, reliability, safety and price, for example, are the top four factors that
consumers have consistently stated they focus on when it comes to making their final decision
about which vehicle to buy, (Environmental Protection Agency, 2010).
Appealing designs, improvement in craftsmanship execution and technology breakthroughs to
keep competitiveness are also major factors to succeed. For example, based on Motor Trend
magazine evaluation the 2010MY Ford Fusion was awarded as car of the year due to the
impressive bandwidth as a model range (Stone, 2009). Another recognition by the Autoweek
magazine, 2013MY Ford Fusion was awarded as the Best in Show at 2012 NAIAS. Ford group
design vice president J. Mays commented, "the Fusion delivers bold styling that projects a more
luxurious message than we expect for its broad, family-car mission. The Fusion is built for the 99
percent; chock full of 1 percent panache and punch" (Autoweek, 2012). The previous reasons
have pushed OEMs to enhance design methods and human capital maturity models in order to
become more competitive with the objective in mind of increasing market share.
For practical purposes, this thesis is narrowed to Ford Motor Company (FoMoCo) in the product
development group. Ford in the USA has demonstrated a high maturity in the organization given
the large years of experience in car systems design, successful vehicle launches worldwide in the
past years and the overcoming of corporate troubles. A good example of the organization
leverage was presented in 2008 during the contraction of the auto-industry, when other North
American OEMs declined, Ford stood firm. This was not causality; there was a plan developed
by Ford in order to keep the company on wheels. This plan incorporated three priorities that
13
embraced the essential needs for the organization: people - a skill and motivated workforce,
products - detail customer knowledge and focus, and productivity - a lean global enterprise
(Hoffman, 2012).
Starting from technical to managerial experience in the human capital until the application of
internal methodologies, such as failure mode avoidance, engineers have shown that during the
development process of a certain project, there are deficiencies to meet deadlines. This behavior
has been noted even more in the satellite PD groups such as the Ford of Mexico office, because
of the young age of the organization which is the driving force for the development of this thesis.
The purpose that I am focusing on with this thesis is the creation of an organizational framework
within the product development group at Ford of Mexico. This bridged the product structure
relationships with the communication and interaction in the organization through the use of
network modeling tools (design structure matrix) and organizational architecture approach.
1.1 Motivation
Thinking about the growing development strategy that Ford of Mexico (FoM) has portrayed,
"people" and "process" are two of the main streams that the company has identified as strong
connection to satisfy high quality designs in short period of time. This has been demonstrated by
the Ford USA product development (PD) structure during the development and launch of more
than ten new "top hat" vehicles in the last five years. A "top hat" is defined as the unique exterior
upper-body and complete interior designs that share a common vehicle platform; also known as
platform derivative product models (Eppinger and Reyes, 2014). For example, the Lincoln MKS
shares the same platform of the Ford Taurus but those are different vehicles to the customer's
eyes. A similar example is the Ford Focus and the Ford Escape; these vehicles are derivative
models from the C platform.
Focusing on "people" and "process" within the company brings huge opportunities to maximize
FoM possibilities to increase "top hat" capabilities in engineering expertise and managerial
matters by always having the objective in mind to attract new programs from the USA
corporation and transform FoM into a global center of excellence in product design and
development.
14
The product development organization at FoM is a complex system because of the large number
of interactions that exist among the different subsystems of the vehicle and the larger amount of
tasks that engineers have to complete for each component that they design. Also there is the
constant increase in the engineering staff demanded by the management and the diverse
capabilities that the workforce shows in a particular project. This organization is compounded by
a spectrum of technical knowledge and experience that goes from novice engineers (those that
recently finished their professional studies) to leveraged engineers who have developed
programs along all the stages of the Ford development process.
Such diversity has brought an interesting effect within the program teams of different projects.
For instance, let's take as a case study the development of a new luxury CD vehicle segmentI
that contains a substantial level of design changes: new engine motorizations, body interior
upgrades, rear end updates and complete front end re-design. The result was a fresh car with
several reworks during the development process. As part of the front end subsystem development
CD project team, I identified that most of the engineers that participated in this program incurred
delivery delays, unplanned communication and product interface mismatches. Figure 1-1 shows
the typical FMA process at Ford, there is lack of a systematic process/framework that enhances
manpower capability; this creates omission while communicating engineering needs. Insufficient
information leads to uncontained noise factors which reduce the identification of potential failure
modes affecting the overall robustness of the product. Deficiencies in the transfer of technical
communication among component teams affect the performance of the project due to reworks in
the design and the hard-work effect. The synergy created between the organizational architecture
DSM and the FMA process might prevent such failure by improving cross-functional team
communication. Component interactions are complemented by the component team structure and
team interactions are validated by the product architecture. Information that feeds noise factors,
control factors and ideal function will be enriched, failures in the product will be prevented and
the program performance will be maximized.
1 A vehicle segment
in the OEM world typically defines the size of the car; they are denoted with the following
letters starting from the smallest to the largest car: A, B, C, CD and D. For example, subcompact cars like Ford
Fiesta are categorized in the B segment, small sedans like Ford Focus are in the C segment.
15
Failure Mode Avoidance Process
QThings gone wrong
HCustomer Satisfaction (i.e.
product JD Power)
@Cross-Functional team
communication
enhancement
-
eComponent
*Component interaction
interfaces
(structural View)
improvement
'Cross-functional Inputs for
component
PI
-Component
nteractions
'Insufficient information from
component interfaces
'Noise Factors not contained
in original development
'input signal, noise factor,
'control factor, ideal
function, error state --
'Ideal Function mislead
'Failure Mode missed due to lack of
interaction among component teams
'Product Failure
prevention
'Rework duringthe development
process
'Low Capabilities in the PD
organization??
Figure 1-1 Lack of Organization DSM in Failure Mode Avoidance Process
The summary mentioned above brings the need of contributing with the growth of FoM PD
organization with the creation of strategies and/or systematic frameworks in order to enable
effective communication and leverage technical knowledge for further "top hat" developments.
1.2 Thesis Objectives and Premises
The development of a new luxury CD platform vehicle at Ford Motor Company was conducted
mainly with FoM PD human capital; the main characteristic of this vehicle consisted in the redesign of the front end subsystem, which integrated 35 cross functional teams. The front end
subsystem group was established with an unstructured network with deficiencies in the
communication process as explained in the section 1.1.
Based on the statement above the objective for this thesis is:
*
To identify gaps in communication among cross functional system teams by comparing
product interaction and the organization structure of the CD-car project to improve
16
human capital capabilities in attracting further "top hat" developments to the FoM
organization.
Supporting this research proposition with the motivation and objectives mentioned above, I have
set up the following premises that will lead the discussion in this thesis:
" Product interfaces are defined with a product architecture DSM; product systems are
developed by teams therefore organization DSMs can lead to the development of a
project having well organized system team structures.
*
Development
and implementation
of system team structures
can improve the
performance of a product team and the outcome of a project.
*
Structured communication among system team members can enhance personnel
capabilities by acquiring experience from cross functional interactions.
1.3 Research Methods and Approaches
I apply the design structure matrix approach and methodologies in this thesis to improve the
FoM PD front end system engineering process. For instance, I develop a product design structure
matrix for the case study in order to determine cross functional component interactions. I build
the interactions based on a front end system boundary diagram from the CD-car vehicle which
comes from research done with the help of Ford core engineering. After I conduct interviews
within Ford of Mexico cross functional component teams from the CD-car case study to
understand the frequency of team interactions and effects of communication presented during the
development process of the front end system project. In addition, I survey the same case study
group to collect technical maturity data to cross reference communication against experience
from the team. Finally, I compare both frameworks to identify gaps in order to portray a strategy
for upcoming "top hat" as represented in the short summary below.
Figure 1-2 Thesis Flow diagram
17
1.4 Thesis Structure
The chapter structure of this thesis is outlined below. Starting from an introduction in chapter 1
premises, objectives and project scope are defined. Brief discussions of the Ford product
development system and detail explanation about the organizational case study are delineated in
chapter 2. Moving to chapter 3, 1 describe concepts about communication, design structure
matrix (DSM) approach and types of DSMs, with emphasis on organizational DSMs as the main
method for this research. In chapter 4, the CD-car case study is modeled using DSMs, analysis of
original data set, system team structure and proposed model structures are conducted in order to
define strategies for FoM. Finally in chapter 5, 1 summarize conclusions and recommendations
from this research project.
Chapter 2 - Organizational Case Study: CD-Car Project
The research presented in this thesis is limited to the automotive industry; I present a brief
description of the product development system at Ford Motor Company in order to bring the CDcar case study for discussion. The scope of this investigation covers the main design phases of
the development process given the maturity of the project. I explain the analysis of the front end
system as the main feature change for the new CD-car. I also describe the program scalability 2
for this project, high level component decomposition and human capital assigned to the program.
Chapter 3 - Communication in the Organization and Network
Modeling Tool
I provide an overview of communication in the organization as soft skill, I explain
communication in the company as a function of distance and workplace; categories within FoM
are summarized, as well. I cover the design structure matrix (DSM) methods; I briefly describe
The program scalability within the
development.
2
OEMs stands for the amount of design changes contained in a new vehicle
18
the types of DSMs focusing on the organizational DSM in order to establish a baseline of
understanding for the application in the CD-car case study.
Chapter 4 - Analyzing the CD-Car Front End System Case Study
I model and explain the CD-car case study using organization DSM methodology having as a
starting point the analysis of the CD-car front end system component interactions. Here contact
and non-contact interfaces are considered. I present original data set from interviews conducted
with the project team. A system team structure is portrayed; I develop a proposed model
structure through software simulation for comparison with component DSM and original team
structure. Understanding of chapter 2 and 3 provides enough foundation for intuitive
reorganization of the front end team structure; here clustering team plays the most important role
to improve interactions among component team for the success of the project. A brief outline
about FoM technical maturity model is explained and cross referenced with frequency of
communication among teams. A picture of cross functional communication before and during a
milestone is presented as contrast of team efforts to deliver the project on time.
Chapter 5 - Conclusions and Recommendations
As final chapter, I recommend to FoM a list of strategies that is needed to leverage the product
development workforce skills. Lessons learned are provided as preventive actions for future
projects. Ultimately, the utilization at the company of organizational DSM in order to establish
right path of communication among cross functional teams.
19
Chapter 2 - Organizational Case Study: CD-Car Project
"I think we are having fun. I think our customers really like our products. And we are always
trying to do better"
Steve Jobs
In this chapter, we look at the vehicle segments that lead to the CD-car project, high level
decomposition of the vehicle system and component decomposition of the front end subsystem.
On the other hand, the scope of this thesis has been limited to the product development process at
Ford Motor Company, starting from the concept development to the detail design. The main
reason of this constraint is given by the core participation of the engineering group and the
program status of the case study. A brief description of the number of changes in the project is
enunciated, which eventually brings concepts of the amount of workforce assigned to the
program.
2.1 Vehicle Segment
Nowadays, different OEMs, regulators and vernaculars have classified vehicles in different
segments due to the car size. Ford has denoted five main segments for its portfolio to satisfy
customer demands: A, B, C, CD and D. Figure 2-1 lists some of the main products categorized
in the different vehicle segments at Ford. Such segmentation represents a strategic division to
cover diverse markets, from North America to Asia and from conventional to luxury.
20
Vehicle Seament
Vemacular
A
Mini Cars
Examples
FIESTA
B
Middle size
Sedan
o
f
CfE
ViGhALE
of
TAURUS
D
ESCAPE
C-MAX
Compact Cars
?AONDEO
CD CD
ECOSPORT
Small Cars
FOCUS
C
B-MAX
FUSION
-1ftA
FLEX
Large Sedan
Figure 2-1 Ford Vehicle Segments
The customer demand has created in Ford the need to expand the vehicle segmentation in an
efficient way; this means that the automaker is creating new vehicle projects. However, they are
keeping the same foundation form, referred to as platforms, for multiple vehicles.
A platform in the auto-industry is a common under-body system 3 that is shared in a vehicle
segment by different upper-body architectures. Platforms are not visible to the customer but they
create high value to the final product. In most times, a vehicle platform is slightly modified in
order to accommodate unique components for a certain program; in other cases, modular system
approaches are used to allow scalability and attribute uniqueness for specific customer needs. A
schematic of the OEM platform is described in Figure 2-2. A platform is mainly comprised of
powertrain, lower body structure, chassis and electrical systems.
3A
vehicle architecture is decomposed in two main subsystems:
a)
b)
Under-body. It contains components designed in the lower portion of the vehicle such as chassis, cooling
lines, exhaust pipes and floor. This is typically known as the vehicle platform.
Upper-body. It contains the upper portion of the vehicle, most of the time visible to the customer for
example, doors, hood, windshield, interiors, etc. In Ford this is known as "top hat".
21
A good example of platform application is the Lincoln MKZ 2013MY; it was developed utilizing
the platform from the Ford Fusion 2013MY. There were minor changes in the platform due to
component incorporation, such as a new reinforcement for the gas strut attachment. This helped
to carefully integrate the platform with the new upper-body; both cars correspond to the middle
size sedan segment.
Powertrain
Lincoln MXZ
Chassis
VEHICLE
PLATFORM
Lower Body
Structure
Ford Fusion
Figure 2-2 Platform Framework
Platforms allow vehicles to be designed in an easier way than if the vehicle were developed from
scratch. Having common platforms across different vehicles allows cost sharing and avoids
much re-development of new components (Ulrich and Eppinger, 2012).
2.2 Automotive System Decomposition
The previous example has shown two different vehicles with the same platform, both of them in
the CD segment. The case study applied to this thesis corresponds to the new generation of the
premium CD vehicle segment for the North American market. The number of design changes,
system architecture and staff allocation to the project will be explained shortly. First, let's
analyze the high level decomposition from the vehicle system shown in Figure2-3.
22
2
Figure 2-3 High Level Vehicle Decomposition
To create a context, the decomposition of the vehicle system represented above was done based
upon the geographic zones of the vehicle that the function lead team at Ford has generated.
These are called operational subsystems which provide a concentrated area for block leaders to
manage. There are four major operational subsystems that integrate the automobile as follows:
1. Front End. In this subsystem, there is a diverse group of components: hood, fenders,
grill opening reinforcement or fascia. A detail list of the front end subsystem for the case
study will be explained in an upcoming section.
2. Mid-Upper-body. Typically this section is the middle upper portion of the car; it is
integrated by components such as front and rear doors, body side and roof among others.
3. Under-body. This is the lower section of the vehicle; it is the foundation where the
upper-body subsystems are mounted. Here, the subsystem is compounded by powertrain,
chassis, electrical, lower body structure, etc.
4. Rear End. In the back of the car, this subsystem incorporates components such as tail
lamps, back light, decklid or rear bumper.
The primary subsystem for the CD-car case study is the front end portion of the automobile. The
rationale behind this case study lies in the number of component teams that integrate the design.
In addition, as part of the design team of the CD-car project, I had the opportunity to identify
gaps in the development process and communication among team members. There was a sense
of incidental interactions, inconsistencies in communication and missing important interactions
which all emerged during the program flow among different component teams.
23
A total of 35 component teams were analyzed from the front end subsystem, the type of
relationships identified were spatial (contact and non-contact) and information sharing based on
three main sources of information:
2.2.1
Product Architecture of the Front End System
Since the analysis of the case study has been narrowed down to the front end subsystem; now we
can utilize the word system to denote the front end. The geographic front end system of the
vehicle integrates multiple components that add high value to the final product. Usually
customers take as a first impression the "face" of the vehicle, determined by the style, geometries
and lines of the exterior-visible parts, regularly known in the OEMs as class A surface.
A good execution of the front end system greatly depends on the interaction strategy specified by
the program teams; this strategy is defined according to the product architecture of the front end
system. The product architecture established for the CD-car project consists in the integration of
body structure, front end module and exterior ornamentation, see Figure 2-4. At this point, the
product architecture has been decomposed at the highest level. The granularity of the system for
the case study has been limited to the second level, given the large number of components that
integrate each subsystem. Table 2-1 shows the complete list of components incorporated in the
physical product architecture of the front end system for the CD-car case study.
W Body Structure
Front End Module
Exterior Ornamentation
Figure 2-4 Front End Subsystem High Level Decomposition
24
Front End Module
Fender
Shotgun Bracket
Body Side
Rocker Panel
Cowl Side
Hinges
Shock Tower Bracket
Hood
Bolster
Lower Vent
Fascia
Fog lamp
Side Marker Light
Grill
Headlamp
Grill Opening Reinf.
Wipers
Engine Cover
Beauty shield
Splash shield
Gap Hider
Leaf screen
Hood Seal
Gas Strut
Overslam Bumpers
Stop Bumper
Latch
Hood Insulator
Table 2-1 Front End Subsystem Decomposition List
2.2.2
Subsystem Boundary Diagram
Exterior-visible parts and hidden components are intrinsically related; the packaging design is
limited by the class A geometries. From this surface, hidden components are designed and
constrained by OEM requirements and attributes; however, interfaces are built based on the
boundary diagram of the system.
A boundary diagram represents the main relationships of a set of components or subsystems that
integrate a system. Figure 2-5 shows the key interactions among the front end system
components and stakeholders that are related to them. There are two types of interactions
considered for the analysis: a) spatial which includes contact and non-contact interfaces and b)
information sharing.
Within the boundary (blue dashed line), the vehicle structure is represented with a combination
of contact and non-contact interfaces, both are spatial interactions. Outside the boundary there
are important relationships with other program teams that have to be considered, as well. The
type of interaction for these relationships is known as information sharing.
25
Body exterior components interact among themselves to meet different requirements, such as
craftsmanship. An example of craftsmanship is the gap distance between the front leading edge
of the hood and the upper edge of the fascia; this is a spatial non-contact interaction. A strong
non-contact interaction exists in order to ensure that the component interface allows a function or
prevents miss function. For the previous example, the right amount of gap between hood and
fascia prevents a hard contact while the hood is being slammed.
Furthermore, spatial contact interactions are presented in the system with the same purpose of
the non-contact relationships, allowing the systems to function. In this case, class A and/or
hidden components are always in touch for attaching, fastening, sealing or supporting among
others. For example, the grill is fastened to the bolster and the overslam bumper is supporting the
hood weight.
An example of information sharing interaction occurs when there is a transfer of information
among program teams. For example, there are constant iterations between design studio and
class A components (hood, fender, fascia, engine cover, etc.). To achieve the desired vehicle
execution, the design studio has to change the design of the class A surface components, these
changes have to be communicated to the proper component teams.
In chapter 4, there will be a description of the product DSM and the main relationships for the
product DSM case study. Interactions were taken from the original front end system boundary
diagram described previously. Although the information is the same, the data is changed from a
structural
view
to
an
architectural
representation.
26
r
- - - -
-
Craftsmanship - - - - - - - - -
- - - - - - -
CD-Car Front End Boundary
- - L
Vehicle
operations
-a
---------------------------i----------------------------
II
II
II
II
Hood Seal
I Fog
I I lamp
I
Side Marker
Light
'I
ml
Bumper
vrlrnI La
screen
I T
I
------L
Fascia
I
j
-
II-
- - - - - - -
-
Headlimpv
-
Bolster
A
S
BuprLatch
GOR
I-
safety
-t
r
4
-4
Ped Pro
-oo
T- r
Hood
-
-d
I
Design
-- - - - 4
-r
Grill
S- - - - Studio
.
-
EID
-
L
-4
- --- -
-
--
-
"11
--
vrsa -a
-
-
II
-
II
"suHoro
II
II
II
I'
II
Finance --
r .i. ..Shock
Tower
- - - - - - L- -
IBeauty
- - -
Shotgun
Bracket
-+ -
Cowl
Side
shield
--
Bracket
L
-
--.-- ..-..
-.-.-
-
GpSls
a HSpla|shieI
Hdrsil
_jd Rocker
Panel
Side
-- - ---
: :
K-- -- ----
-------------.-- - ---
I
- --
-
-- I
I Strut
4-;II
II
II
Ii
II
Ii
Ii
II
II
Ii
II
II
II
Ii
Ii
I
~~1~
Fender
IHi
FGas
I.
LI
L .
......--....
-------------------------------------------------
Contact
Non-Contact
Info sharing
2.2.3
Product Module Team
The third source of information utilized to determine the number of component teams is the
product module team at Ford. The product module team (PMT) is the denotation for the
subsystem team groups. These groups are integrated by function, whose function is to deliver
forward model programs at functional cost, timing and quality targets (Ford Speak, Internal Ford
Network, 2014).
At Ford, a global team structure is decomposed in seven main PMT groups: body exterior, body
interior, chassis, powertrain, electrical, hybrid technology and vehicle personalization. All these
groups speak among themselves as an organized structure. Each group is decomposed in several
subsystems; however, they do not communicate as organizational architecture. Given the nature
of the design changes of the CD-car project, I selected the PMT body exterior team as the main
system for analysis. This PMT has also seven subsystems, three of them have been taken as case
study. A decompositional view of the global PMT structure is represented in Figure2-6.
Figure 2-6 Global PMT Structure
28
2.3 Project Size
In Ford, the scalability of a program describes the content change level in the product, generic
timing and development cadence of the vehicle. Typically, product changes are reflected in the
three domains of the automobile: upper-body, under-body and powertrain. The change levels are
measured with a descendant scale from #6 to #1, where #6 means all new and #1 indicates no
change or carry over components as shown in Figure 2-7.
For the CD-car project, the program team has specified the scalability of the product as a middle
cycle action design 4 with a nomenclature of 433. This means that there is a moderate upper-body
style with predominant changes at the front end of the car. The under-body suspension has partial
changes and the powertrain is being tuned to achieve emission efficiency.
Scale
Upper body
Under body
Power train
(UP)
(UN)
(PT)
6
AJ new
Al new
Al new
5
Major change
Major change
Major change
Moderate
Moderate
4
Moderate
Partiay Moderate
3
Partaly Moderate
r
2
Minor
Minor
Minor anost carry over
1
Badge work
No change / carry ove r
No change / carry over
J
Figure 2-7 Program Scalability Framework
Modified from FoMoCo
4 A Middle Cycle Action design is launched at the middle of the life cycle of a vehicle program. This is a refreshening
model that drives the design of an all new top hat vehicle.
29
2.4 Product Development Process
Product development process is a series of steps which tasks are developed under a certain
methodology; the process leads the design of a new product in order to commercialize it in the
market.
The perception of market opportunity drives the design, production, sale and delivery of products
(Ulrich and Eppinger, 2012). Competition, market change, product life cycles and technology
advancement are elements that push PD organizations to develop products more efficiently and
more frequently (Unger and Eppinger, 2011). Other bibliographies have described the
transformation of information as the main characteristic of product development, along different
stages of the PDP workflow (Aguirre, 2008).
Transformation
of information occurs during the exchange of data among different
organizations. For example: marketing, finance, purchasing, manufacturing and quality. The
interactions of these groups provide input to the main PDP activity; at the same time the PDP
generates outcomes for the other entities that participate in the process. The success of the
product design highly depends on the level of communication from different organizations,
which ultimately will produce the maximum market penetration of the product.
Nowadays, there are different product development processes utilized by companies in function
of their needs. For example, the spiral process incorporates planned tasks with feedback loops,
which allow the PD team to go back in the process for issue resolution or detail design. The
spiral process also incorporates flexibility in designs and reviews among stages in the process,
Figure 2-8.
On the other hand, one of the most popular PDPs is the staged process. It is used by companies
that iterate a few times; they follow methodic steps and typically stop the design process at the
latest stage in order to stabilize the product. This PDPs reduce reworks and design changes. This
process is applied to product design in cycles with high quality performance as explained by
Unger and Eppinger in their journal Improving ProductDevelopment Process Design (2011).
30
/
Integration
Land test
System-level
design
Tm
Release
Planning
Con cept
Figure 2-8 Generic Spiral Process
Source: Unger and Eppinger, 2011
hnproving product development process design: a method for managing
information flows, risks, and iterations
According to Ulrich and Eppinger (2012), the generic product development process is like the
process used in a market-pull situation. The company identifies a market opportunity and then
uses a proper technology to satisfy market needs. Variants derived from the generic development
process exist, as well. Ulrich and Eppinger (2012) have defined the following:
" Technology-Push Products: a new technology pushes the product development. After
this, the company looks for market opportunities to create a new product.
* Platform Products: the platform product is built around a pre-existing technological
sub-system. Products built on platforms are simpler to develop compared to technology
developed from scratch.
*
Process-Intensive Products: there is a major restriction from the production process on
the product. Product design cannot be separated from the production process design.
*
Customized Products: a product is developed based on particular requirements of a
customer. A company executes a structured design and development process to create a
product that meets customer needs.
31
*
High-Risk Products: products are developed under large uncertainty where there is high
technical or market risk. Here, multiple solutions are developed to ensure one succeeds.
" Quick-Build Products: on this variant, products are developed in a very short time
taking advantage of rapid prototyping; flexibility in the process is added in order to
reiterate through the development phases.
*
Complex Systems: large-scale products such as automobiles and airplanes are complex
systems composed of many interacting subsystems and components. System level design
is critical; system is decomposed in subsystem and then in components. A program team
is assigned to develop each component. In addition, integration teams are allocated for
component integration and testing.
Although there are several variants in the product development process, the generic process
phases are well defined. Based on Ulrich and Eppinger (2012) theory they are:
-
Planning: during this phase product portfolio, timing and product development process
are developed. Strategies for product technology are set up to full fill market needs;
production and supply chain strategies are identified, as well.
-
Concept development: this phase involves customer need identification, benchmark
analysis and manufacturing assessment. Economic analysis is also performed.
-
System level design: product architecture, sub-systems and components are defined in
this phase. In addition, product specifications and assembly processes are developed.
-
Detail design: complete product specifications are established, process and control plans
are specified, as well.
-
Testing and refining: this phase incorporates component and system validation of
prototype parts, according to specifications. Part failures are identified; product
improvements are implemented in the design.
32
-
Production ramp-up: in this phase, the product is released utilizing the design
manufacturing process. Tool trials and operator training take place during this phase.
Design intent and process are matched to launch final product.
In the automotive field, OEMs typically utilize the staged product development process for
automobiles development. The simplified process of the staged framework can be summarized
by four main activities: define, design, validate and launch (Lopez, 2014).
Within the four steps previously mentioned, Ford has incorporated major milestones that
combine program management waterfalls and design activities, which allow the design in cycle
of new products. Figure 2-9 compares the generic staged process from Unger and Eppinger
(2011), simplified process and milestones characterized by Ford.
a) The Define phase includes marketing operations. The program collects customer vehicle
preferences for approval; then the program begins. In parallel, the design team initiates
the development of concept alternatives, few iterations are considered before a vehicle
theme is accepted.
b) During the Design phase, the program defines high level strategies from different
organizations in the PDP, targets and sourcing are determined, as well. The vehicle theme
is created and the preliminary system architecture generated; the engineering team starts
preliminary feasibility analysis. The program team refines targets and strategies; this
allows engineers to deeply analyze the design before it freezes. Manufacturing teams
develop the assembly lines for the new product. At the end of this stage, the design,
targets and strategies are frozen. Bill of materials is mapped and early prototyping phase
starts for validation. Program objectives and economics are approved, as well.
c) In the Validation phase, prototypes are available, system and component validation takes
place. During testing, preliminary validation and final validation sign-off are completed.
At this point the product is ready for launch. Tool trials are prepared for assembly process
and validation.
33
d) The Launch phase incorporates assembly line trials to validate product versus tool,
system compatibility is evaluated and supplier quality checks are conducted. Production
ramp-up starts.
General Staged Process
Planning
Concept Design
System Design
Detailed Design Iterations
Integration and
Testing
Reas
Reese
Simplified
Define
Validate
Design
S
fm
Launch
.oloi
-.w WN
Ford PDP
CRmp.
.
Milestones
Design
phase 0
Design
phase 1
Design
phase 2
Design
ReleaseO"'
Figure 2-9 Staged PDP Comparison
Modifiedfrom Unger and Eppinger, 2011
The CD-Car case study has been limited to the analysis of the second half portion of the
definition phase and the complete design phase (red dashed box from Figure2-9) which included
four main milestones: design phase 0, design phase 1, design phase 2 and design release. The
scope was narrowed to that portion of the development process, because during the early define
phase, the engineering team did not have major tasks. Validation and launch steps incorporated a
new engineering group called production vehicle team; tasks prior to these stages were done with
the original team that was researched for this thesis.
34
Chapter 3 - Communication in the Organization and Network
Modeling Tool
"Iam a great believer that any tool that enhances communication has profbund eftects in terms
of how people can learnfrom each other, and how they can achieve the kind offreedoms that
they are interested in"
Bill Gates
Product development performance is highly defined by the effectiveness of communication in
the organization. Technical communication in the development organization is determined by a
combination between product architecture and organizational architecture (Sosa, Eppinger and
Rowles, 2000).
In this chapter, we start with the definition of communication and types of communication in an
organization. These concepts will lead to the communication in technical organizations and the
effect of the communication at the work place. The organizational structure and physical space
also play an important role in the product development success. For example, flow of
communication in the product development organization from two different locations: United
States and Mexico. A framework of categories in communication and techniques for increasing
communication awareness will be explained.
The relationship between product design and organization management can be modeled utilizing
a network modeling tool called design structure matrix. DSM's definition and process are stated
in this section. There are four primary types of DSM described by Eppinger and Browning in the
book Design Structure Matrix Methods and Applications (2012): product, process, organization
and multidomain; the detail for each one will be defined later. Method for clustering analysis is
listed with the explanation of cluster meaning. In the latest portion of this chapter, I will show a
couple of examples to illustrate product and process DSMs. In depth discussion for
organizational DSMs will be stated in chapter 4 in order to create a baseline of knowledge for
application case.
35
3.1 Communication in the Organization
Communication can be defined as the exchange of information between two or more individuals
in order to achieve a desired goal. The communication process can be executed with language,
sounds, signals or gestures; this is the code that the communication parties utilize. To enable
effective communication the transmitter should be able to provide the message in a proper
codification, this will allow the receptor to decode the information and process it for replication
to the transmitter. The process is reverted once the information was analyzed, receptor becomes
transmitter and vice versa. In addition to the usage of code for communicating, there should be a
channel to transmit the information, such as radio waves, paper or data.
In technical organizations, communication of information can be transmitted in multiple ways;
for example, face to face interactions, phone calls, video conferences, text messages or emails.
The effectiveness of communication is given by two elements: a) frequency of interaction and b)
quality of information exchanged. The transfer of information for the development of innovative
new products depends on the organization's knowledge and task to manage knowledge; however
the success of the process requires the organization to access, maintain and transfer knowledge
among individuals (Allen and Henn, 2007).
The development process of a product typically involves a high number of tasks; these tasks are
developed by a determined number of people. When the product becomes more complex, the
project requires more workforce which at the same time increases technical communication;
similarly, the network in the organization is expanded. The program management should
recognize the difficulty by having a larger network of communication; frequency of interactions
is reduced and quality of information exchanged is deteriorated. Another challenge in product
development organizations is the geographical barriers to communicate within the organization
(Morelli and Eppinger, 1993). These barriers have emerged due to the need to expand worldwide
the product development organization; that is executed by utilizing low cost resources and
strategic locations for designing new products. Global product development operations require
cross functional teams divided in several groups segregated over a region (Dean and Susman,
1989). Even with the segregation, communication barriers persist such as language, culture or
time difference. For example, in the latest years Ford Motor Company has developed several
programs globally, having the product development team in USA, design studio in Germany and
36
manufacturing operations in China. It is understandable that the combination of different regions
for different product development entities create big challenges in communication. Nevertheless,
"enhancement of communication between engineering groups on the same floor (e.g. doors and
body sides groups) is also a big challenge in communication" as commented by side closures
manager at GM Grant Nelson (2014). Further explanation about this behavior will be discussed
in the Communication at Workplace section.
We have enunciated previously that the performance of a product development organization lies
on how effective is the communication. However, there are barriers in the network that create
high risk on the delivery of communication. Aguirre in his thesis Designs of Product
Development Systems (2008) has specified that if the organizational structure is designed
properly then there will be flexible risk capability. This means that there is a clear understanding
about who should communicate with, in terms of frequency and quality. There would be a good
understanding on the level of responsibilities from each group in the product development
process. When every portion of the organizational network matches the responsibility to the role
(Aguirre, 2008) transfer of communication will flow smoothly.
To have a better understanding about knowledge transfer, technical communication in the
product development organizations can be divided; for the purpose of this thesis I will focus on
the type of communications framed by Thomas Allen (1986). He has developed three different
types:
"
Communication for coordination. Multiple engineering teams communicate in order to
coordinate the work progress of a project.
" Communication for information. Information is transferred in order to keep the
organization with the latest level of data in a project.
Communication for coordination and information typically are concentrated in the organization
structure. Allen and Henn (2007) explained that structuring organizations determine how
different project teams relate to each other. The interaction of the team is critical to managing
cost, performance and schedule. An example of organizational structures for coordination and
37
information in Ford USA is the body closures and the stamping business unit. The body closures
team is in charge of leading the design and development of sheet metal components such as
hoods, doors or decklids. These components are integrated by large panels, which need
feasibility analysis for stamping formability. In parallel, the stamping business unit designs and
develops the die tool which comes from the body closure design. The coordination of work
progress and transfer of knowledge takes place in the same area of the building (e.g. 2D zone).
The array of the organizational structure was laid down having a mirror layout. This means that
for each body closures engineer there is a stamping designer. The workplace is divided by
manager offices which act as awareness area as shown in Figure 3-1. The communication
between engineering and stamping teams flows in two ways; for instance, engineering provides
3D CAD data to the stamping group for analysis. After the data is analyzed, the stamping team
gives feedback to engineering for geometry improvement. Stamping also requests engineering
material specifications and sheet metal blank size among others.
Stamping Business Unit
-
Manager Offices
01
2Dzone
Body Closures Team
Figure 3-1 Body Closures and Stamping Unit Layout
*
Communication for inspiration. This type of communication is cross disciplinary and
cross functional occurring spontaneously with the objective of generating creative
solutions to issues in a certain project (Allen and Henn, 2007).
38
The bibliography from Allen and Henn (2007) also discussed the difficulty to find organizational
structures designed to manage communication for inspiration. Knowledge creation can be
addressed by having common spaces to increase the level of interactions between project teams
as exemplified in the Hallmark case.
Common spaces centralizing communication for inspiration can be seen in technology
companies. For example, HubSpot is an inbound marketing company whose objective is to
increase sales to other companies through software application. This business has implemented
several common spaces to increase knowledge creation and data exchange.
Appliances and distinct features were added: the cafeteria is like a "candy shop" full with colors
and unique dinner tables; there is a game room with soccer and pool tables, a rock-band area was
also combined with the working offices. All these areas function by bringing people together
from diverse locations of the building, which enable conversations for problem solving through
creative ways.
Figure 3-2 HubSpot common spaces
Source: https://www. kareer.ine/discov,er/hubspot-inc
Common spaces are created to stimulate thinking, conversing and creativity; which drive
innovation in technical organizations, per Allen and Henn (2007) theory.
39
3.2 Communication as Function of the Workplace
In a technical organization, there is always the need for creation of new products, processes or
methods for new markets. The activity designated for those needs is the innovation. Innovation
has several definitions that vary from industries; even the definition has been differentiated by
experts in the matter.
For the purpose of this thesis, we can define innovation as the development of new products or
services; renewing or changing a process or product, or simply the improvement in the way how
things are done. Innovation is a sustainable growth for a business (Lopez, 2014).
Managing the innovation process depends on the organizational structure and physical space
(Allen and Henn, 2007); human capital is organized through different forms: hierarchy, project
team or function lead teams. On the other hand, workplace configuration depends on how
managers set communication channels that facilitates the organization's knowledge creation.
Organizational structures raise capability and coordinate abilities; they encourage technical
specialization, and cross functional communication (Gulati and Eppinger,
1996). These
characteristics are influenced by the grouping of people in the organization, represented in
organizational charts. Layout of the office and proximity of people working in a project are
determinant for the organization as explained by Allen and Henn (2007).
A)
B)
Figure 3-3 Hierarchy and Closed Workplace
Source: Allen and Henn, 2007 The Organization and Architecture of Innovation: Managing the Flow of Technology
40
In Figure 3-3, there are two different types of organization structures. Organization A) is a
hierarchy representation that enables information top-down; the exchange of communication
flows from the upper management to the first line workforce. This configuration limits
knowledge exchange for creative solutions, coordination between project teams is rarely
established given that the transfer of information comes downwards, and not lateral. In contrast,
structure B) represents a physical open space, knowledge transfer is exchanged among people in
multiple ways; communication is encouraged and there is no restriction from the hierarchy.
Similarly, Ulrich and Eppinger (2012) have explained that a product development organization is
the scheme by which individual designers and developers are linked together into groups.
Organizations are formed by establishing links among individuals; links may be formal or
informal which may include the following according to Ulrich and Eppinger (2012):
-
Reporting Relationships: these are formal links visualized on organization charts,
relationship among hierarchy elements are represented.
-
Financial arrangements: team members are related when they are part of the same
financial group, for example: a particular budget category or profit-and-lost statement.
-
Physical layout: links between individuals are shown when they are in the same
workplace area, facility or site. Links are informal and encounters among people are
spontaneous.
In addition, Ulrich and Eppinger (2012) have stated that individuals in a product development
organization can be categorized based on the function or the project they are participating in.
Figure3-4 shows various product development organizations.
3.2.1
Functional Organization
In terms of organization, an area of responsibility usually involving specialized education,
training or experience is known as function. The product development organization incorporates
41
functions such as marketing, design and manufacturing. In functional organizations, the
organizational links are primarily among those who perform similar functions (Ulrich and
Eppinger, 2012).
3.2.2
Project Organization
A project is a set of activities in the development process for a particular product which includes
tasks such as customer need identification and product concept generations. On this
classification, organizational links are primarily among those who work on the same project.
This organization would be made up of people from different functions focused on the
development of a specific product (Ulrich and Eppinger, 2012).
3.2.3
Matrix Organization
This organization is classified as a combination of function and project; individuals are linked
according to the project they work on and their function. Each individual typically has two
supervisors: project manager and functional manager (Ulrich and Eppinger, 2012).
There are two variants of the previous classification denoted by (Hayes et al., 1988):
heavyweight project organization and lightweight project organization. The first variant contains
strong project links. Heavyweight project teams in various industries may be called integrated
product teams, design-build teams or product development teams. On the other hand, lightweight
project organizations contain weaker project links and strong functional links (Ulrich and
Eppinger, 2012).
42
Geneial
Manager
Functionol
Managers
0
00] < <1
General
0I 0
0 00
-
j---
<1
<1<
Maagr
PEL
O
LIE 7DK'
IEDC
J~
-
[3J 00O <1<
Funetionel
Orgpanization
Project Orgpnization
neral
lGiManager
Functional
FunCtiosn4
Managers
Pro~r
WWeihtwihPrjc
e
rgnai
Pro-ect
Aduxi hm I hyu a &L, 19*
Figure 3-4 Various Product Development Organizations
Source: Ulrich and Eppinger, 2012 Product Design and Development
3.2.4
Examples of Communication in the Organization
Allen and Henn (2007) argue that business organizations can be seen as social organizations
which have needs in organizational and spatial levels. These aspects are important because they
lay under the area of influence of management (Aguirre, 2008). The way an organization is
architected in a business impacts performance in a project team; it has this main elements:
managerial structure (Figure3-4), interaction process, culture and competences.
The location of people at the workplace has an effect. There are two critical characteristics that
induce such phenomena: physical location and distance between people. The way these elements
are laid in the organizations either promote or deteriorate the interactions in the project teams;
communication is affected as well. Most of the time there is a need to set up additional
43
mechanisms to counter negative impacts. For example,
a
close
workspace
can
be
transformed into an open space; this configuration encourages all types of communication. That
can be achieved for example, when manager's offices integrate glass walls which ensure that
executives are visible to everybody, as explained by Allen and Henn (2007). Another key
element seen in their literature is the common space. This area not only enables creativity among
people but also pulls managers out from their offices to create encounters with colleagues and
employees.
Previous elements can be seen in the Skoda automotive assembly plant where manager offices
are located along the central spine surrounded by the production line. The center of activity is the
interaction between managers and workers on the line; physical open spaces allow interaction
(Allen and Henn, 2007).
Figure 3-5 Skoda automotive assembly plant
Source: Allen and Henn, 2007 The Organizationand Architecture of Innovation: Managing the Flow of Technology
Another example of communication flow as function of distance is the case described by Reyes
in the write-up The Flow of Communication in Space: The Body Exterior Organization Case
(2014), as follows:
44
The North American PD team includes Ford USA and FoM PD organizations. The FoM body
exteriors office is a departmental organization encapsulated in a single floor of a building
integrated by a total of 6 floors, Figure 3-6 a). This office is located on the third floor of the
building with no visibility to other groups; this limits the communication network with the PD
organization. The physical location of the body exterior team and the structure of the physical
space reduce the probability of a pair of people communicating with each other; this is
represented in Figure3-6 b) by Allen and Henn (2007).
Probability of Communication
00
0
_2
0
-
-
-
0
20
40
60
80
100
Distance (meters)
Figure 3-6 a) FoM Building, b) Probability of Communication
Source b): Allen and Henn, 2007 The Organizationand Architecture of Innovation: Managing the Flow of
Technology
The previous effect in communication within the FoM organization is heavily noticeable; it is
unusual to see engineers going from the third to the upper floors to attend face to face meetings
with the program teams. Instead they interact by phone, typically because of the minimum level
of technical communication that they exchange; in most of the cases the meetings are related to
program status or bulletins.
That behavior fits Allen's framework about the communication medium as a function of distance
of low complexity information; telephone is highly used when communication subjects are
simple even in short distance as shown in Figure 3-7.
45
Figure 3-7 Low complexity information
Source: Allen and Henn, 2007 The Organizationand Architecture of Innovation: Managing the Flow of Technology
The FoM PD group as part of the North American organization plays an important role in the
development of body exterior systems. However, the distance between both offices affects the
effectiveness of communication. Although this example may sound obvious, there are deeper
issues.
Firstly, there are cultural and personal differences, time zone differences and long distance
separations between countries. These characteristics between the work spaces create challenges
of getting people to talk with each other and transfer effectively technical knowledge. The
natural medium for communication given in this case is the use of media tools such as video
conferences, webex and frequently the telephone. Nevertheless, when there is a need to transfer
complex information among teams (e.g. CAE analysis at system level) or when important
milestones happen during the product development process (e.g. component financial
statements), it is necessary to interact face to face with the program teams even when the
distance is extended as represented in Figure 3-8.
The FoM PD group has portrayed the strategy of business trips in order to establish face to face
communication between sites; most of the engineers in the organization have business trips as
part of their assignments to interact face to face with their counterparts in USA. With this
46
strategy, the team makes sure that the communication flows successfully and the program tasks
are complete in form and time.
Figure 3-8 High complexity information
Source: Allen and Henn, 2007 The Organization and Architecture of Innovation: Managing the Flow of Technology
As contrast, the USA PD work physical space is located in a two floor building with a spine that
interconnects the different PD teams. However every single team group has semi-open spaces at
the center filled with manager offices like the body exterior group, Figure3-9.
DirectorOffices
Body
m
-
--Ext. CAD
ww
FR
Body
Int. CAD
ManagerOffices
-
DI
PMTs
Body ExteriorGroup
B
Body Interinors/
Bod y ExteriorGroup
Design
Studio
Figure 3-9 Body Exterior Departmental Organization
47
These spaces act as awareness areas because there is high flow of interaction and communication
among team members of the department. For instance, the amount of people that is localized in
these areas are smaller groups that have to communicate to each other technical matters or
program reviews. In any case, the probability of communication is increased as explained by
Allen and Henn (2007) in Figure 3-10.
C
I
0.
Smoothed P(C)
S0RawData
E
E0 0.6
-Power
(Raw Data)
M
0 0.4
0.2
0
a
0
10
20
30
40
50
Size of Department
Figure 3-10 Departmental Size and communication
Source: Allen and Henn, 2007 The Organizationand Architecture of Innovation: Managing the Flow of Technology
The physical configuration of the space and the organizational structure of the human capital
allow the process of innovation, as described in a previous section. For example, during face to
face technical design review meetings of a certain matter (e.g. corrosion issues in aluminum
sheet metal panels) a variety of opinions are exchanged in the group, lessons learned and best
practices from different programs are shared as well; this means that the flow and application of
ideas take place to solve particular issues.
Another important finding is the fact that people that have worked in a program that is ending
sometimes are moved to another section of the office in order to increase interdepartmental
communication. These interactions allow transfer of experiences to prevent failure modes in the
products.
48
3.3 Various Frameworks of Communication
We have described that communication is influenced by the workplace and how to overcome
constraints in organizations. However, the response that project team members should provide to
surpass such constraints is an open question.
3.3.1
Leadership Perspective
A team member can be considered as leader in his own role. For example, he delegates tasks to
other project teams; he reconciles groups or simply restores communication breakdowns.
The team member should be responsible for his actions and certainly capable to overcome
communication constraints. Saada Saar and Hargrove in their book Leading with Conviction
(2013) have illustrated that communication is a process that should be captured by leaders.
Essentially they do not have to remain silent. Instead they have to over-communicate. If the
wider organization is not kept in the loop, naysayers cluster and subcultures start to proliferate
(Saada Saar and Hargrove, 2013).
In a leadership environment, over-communicate means to conduct intensive sessions with people
at all levels to communicate changes, report on progress, solicit feedback, and enable people to
express themselves by sharing their own narratives (Saada Saar and Hargrove, 2013). The
previous idea expresses good will but there is no structure identified in order to allow team
members to overcome communication restrictions.
3.3.2
FoM Approach
Ford of Mexico has portrayed an idea to overcome those constraints by improving
communication capabilities among engineers. Table 3-1 characterizes four quadrants of
communication awareness.
The awareness framework corresponds to the engineer by himself and not among engineers. We
first have to understand if engineers know how to communicate: Q1 indicates that engineers
think they know how to communicate but they do not know about their poor communication
skills; in the second quadrant, engineers are aware that they need improvement in
communication skills. in Q3, engineers do not know they are good communicators but they
49
perform well. Finally, in the fourth quadrant, they know that they communicate well and they
know how to execute.
"They donI know that they know"
"They know that they know"
04
I
01
"They donI know that they don? know"
Q2
"They know that they donI know"
Table 3-1 The know-don't know quadrant
Source: Diaz, 2014 Evolved Technical Maturity Model
Once the communication awareness is identified, FoM applies mechanisms to move to the fourth
quadrant. These mechanisms have been consolidated in communication training with specialized
firms by exposing engineer's real talents. However, this action does not guarantee effective
communication among project teams. There is no framework yet that interconnects engineering
interactions between team members.
3.3.3
Lean Design Principle
Womack, Jones and Roos in the book The Machine that Changed the World (1990) stated that
lean design has established communication as a means to resolve critical design trade-offs.
50
Confrontation of these trade-offs are faced upfront in early stages of the design process. This
leads to the correction of problems before they multiply and ends up with much less total effort
and higher quality in the end (Womack, Jones and Roos, 1990). These authors have also
compared sequential against simultaneous developments. The first idea indicates that an activity
can be done once the previous task was complete. Whereas, simultaneous development involves
several tasks done in parallel which results in less costs and less human effort (reworks
avoidance). Yet the simultaneous development does not lie in the completion of parallel tasks but
the intense communication between project teams during the development of a product
(Womack, Jones and Roos, 1990).
Womack, Jones and Roos (1990) have exemplified such communication with the Honda design
and cutting dies case. Die designers know the size of the new vehicle and number of panels to
order die steel blocks. They also identify the panel design process, and then the panel designer's
final solution is anticipated as well. In parallel, die makers prepare scheduling production at the
die cutting shop to achieve flexible cutting machines for product evolution. The result is the
production of dies in one year which is half the time needed from other OEMs.
The previous example shows how well Honda has identified critical interactions between two
project teams. These interactions are working tasks strongly linked between die designer and die
makers; the channel and degree of communication should be established upfront per lean design
principle.
Continuing focusing on people interaction for lean development, Womack, Jones and Roos
(1990) pointed out that intense communication enhances product development performance.
Table 3-2 provides an outlook of product development performance for different regions of the
auto industry in the mid 80's. It is clearly seen that producers that utilize these methodologies
like Japan get the best performance. Another study conducted in an European OEM dedicated its
attention to evaluate challenges by the implementing of lean product development such as
difficulties in communication, flow of information and knowledge transfer, among others. The
summary of the research found that socio-technical dimensions have become more complex and
unmanageable. Volume of interaction between teams through the product development process is
still a key challenge that auto makers have to address (Saunders, Gao and Shah, 2014).
51
Product Development Pertormance by Regional Auto industries, Mid-1980s
Jep...se
Prenucenr
Amran I#
Pi"vcn
Ewoean
mw SWpItihll
Pbeswen
Euroyoss
Pmesewe
Average Engineering Hours per New
Car (millions)
17
3 1
29
31
Average Development Time per New
Car (in months)
46 2
60 4
57 3
59.9
Number of Employees in Project
Team
485
903
904
Number of Body Types per New Car
23
1 7
27
1 3
Average Ratio of Shared Parts
18%
38%
28%
30%
32%
14%
37%
51%
Supplier Share of Engineering
Engineering Change Costs as Share
10-30%
30-50%
10-20%
of Total Die Cost
1 in 3
1 in 2
1in 6
Ratio of Delayed Products
28 0
25 0
13 8
Die Development Time (months)
10 9
4
12
2
6
(months)
Time
Lead
Prototype
Time from Production Start to First
2
4
1
Sale (months)
Return to Normal Productivity After
12
5
4
New Model (months)
New
After
Quality
Normal
to
Return
12
11
14
Model (months)
World
Source Kim B. Clark. Takahiro Fujimoto, and W. Bruce Chew, "Product Development in the
Auto Industry, " Brookings Papers on Economic Activity No. 3, 1987; and Takahiro Fujimoto,
of the Global Motor Industry."
"Organizations for Effeclive Product Development The7Case
Ph.0 Thesis, Harvard Business School, 1989, Tables 1, 7 4, and 7.8
Table 3-2 Product Development Performance comparison by regional auto industries
Source: Womack, Jones and Roos, 1990 The Machine that Changed the World
Multiple researches in lean design and product development have indicated that communication,
integration and transfer of knowledge are key characteristics for project success. Lean design
incorporates additional elements that improve people capability and performance at the
organization; however, there are still complex challenges to overcome like knowledge
management and communication transfer.
3.3.4
Organization in Product Innovation
The development of new products in technical organizations requires frameworks to properly
allocate teams and facilitate cross functional interaction for different projects. Clayton M.
Christensen in The Innovator's Dilemma (1997) has framed an organizational structure that
mirrors the product architecture of a system represented in Figure 3-11.
52
The explanation of the behavior starts in early stages of industry's history. Technical efforts are
focused on architectural innovation; product designs tend to be integral meaning that individual
components are integral to other components and projects are managed by integrated teams.
However, when a dominant architecture emerges, the application of technological energies tends
to improve performance and cost-effectiveness of individual components and subsystems. Once
there is a shift from architectural to component innovation, technical groups tend to be organized
in firms to focus on component improvements and specialization takes place within specific
functions (Christensen, 1997).
Moreover, Christensen (1997) exemplifies the previous analysis with an OEM firm in charge of
designing steering gear; the team will be organized in groups that mirror the components of the
steering gear system: steering column group, rack-and-pinion gear group, tie rod group, power
steering pump group, etc.
Product Architecture
Component A
Component
Organizational Structure and
Interaction Patterns
0
F
Component D
Component F
Group F
Figure 3-11 The Organizational Structure Mirrors the Established Product's Architecture
Source: Christensen, 1997 The Innovator's Dilemma
The way components work together is defined by the product architecture. It has been found that
the pattern of interaction and communication between individual and teams of the organization
53
mirror the structure of component interfaces within the product architecture, organizational
structure and working patterns serve a company when innovation is modular (Christensen, 1997).
In addition, Sosa, Eppinger and Rowles (2000) have also questioned how the product
architecture and the system level of the development organization map into each other. This is
due to the similarity of design interfaces of a product and team interactions, Figure3-12.
DeveSopput
Product
Syu=e
Organization
Systea B
A
Group A
rpB
Sysmw-vel iharvtin
Fm
eamplComp
Destinterfaces d fre
the pdct ncohitature
.k
Team interactions
h
etoinTeam
Bk
integr te the components
Figure 3-12 Design interfaces and team interaction similarity
Source: Sosa, Eppinger and Rowles, 2000 Understanding the )ffects of Product Architecture on Technical
Communication in ProductDevelopmnent Organizations
From the previous example, component teamns know that they have to interact based on
component interfaces. These are integrative
systems whose components are physically
distributed throughout the product resulting in components sharing interfaces (Sosa, Eppinger
and Rowles, 2003). In contrast, groups that rarely interact are those whose components have no
interface or very minimal relationships; these are modular systems which do not share design
interfaces that belong to other systems (Sosa, Eppinger and Rowles, 2000).
54
3.4 Approach and Design Structure Matrix Methods
Reflecting about the complexity of an automobile system, typically a vehicle is made up of more
than 10,000 components with multiple interfaces; this product is categorized as complex system.
So, how do you organize people to design, build and put all system pieces together?
In order to frame the answer of previous question, we have to conceptualize the meaning of
product architecture and further understand the approach taken by Scholars that have studied
similar complex systems. The same approach will be used in this thesis to explain the CD-car
case study.
-
"Product or system Architecture is defined as the embodiment of concept, and the
allocation of physical/informational function to elements of form, and definition of
relationships among the elements and with the surrounding context" (Crawley, 2013).
-
Ulrich and Eppinger (2012) have simplified the definition as the arrangements of
functional elements into physical blocks.
In a journal article related to the research of a large commercial aircraft engine design, Sosa,
Eppinger and Rowles (2004) have described a novel approach to compare the architecture of a
product with the development organization which designs engine components. According to
these authors the method consists of three different steps:
They started by A) comprehending how to capture the product architecture, which allows
visualization of the landscape of component interactions in the system. B) Capturing the
development of the organization helps to identify the design team responsible for developing
the project's components. This is achieved by surveying project members to capture frequency
and importance of interactions among them. C) Finally, they compare the product architecture
with the development organization to answer the following key questions:
How accurately can we predict communication coordination by analyzing the coupling of
product architecture and the structure of the development organization?
Why do some design interfaces between components not correspond to technical
interactions between teams that design them?
55
Why do design teams that develop independent components still engage in technical
interactions?
Firstly, to capture the product architecture, we have to understand the different part dependencies
presented in the system. The design interaction between physical components integrates five
types of design dependencies (Pimmler and Eppinger, 1994):
-
Spatial, this dependency specifies the need of physical adjacency for alignment,
orientation, serviceability, assembly, weight, etc. For example, in vehicles, hood to apillar shall maintain a hood swing clearance to ensure the closing and opening of the
closure subsystem.
-
Structural, dependency indicates existence of functional requirement for transferring
design loads, forces or containment. Utilizing the hood subsystem as an example, hinges
should withstand load transferred from the hood weight and kinematic moments when
hood is in motion.
-
Energy, functional requirements related to transferring heat energy, vibration energy,
electrical energy or noise. For example, the hood insulator attached to the hood
subsystem is designed to prevent heat transfer from the engine to the sheet metal. In
addition, the insulator provides a seal to the holes added into the hood inner panel.
-
Material, dependency indicates a functional requirement related to transferring oil,
water, air or fuel. For example, hood washer nozzles depend on water to deliver the
function; nozzles conduct pressurized water to spray it to the windshield.
-
Information, dependency indicates functional requirement related to transferring signals
or control. An example can be seen in the hood latch assembly; the mechanism transmits
a signal to the close/open sensor which depends on the presence of the striker rod.
Once interfaces are identified, critical dependency is captured for the functionality of the
component analyzed. Pimmler and Eppinger (1994) also have proposed five point levels to
measure the level of criticality as represented in Table 3-3:
56
Level of design
dependency criticality
Required
Desired
Indifferent
Undesired
Detrimental
Description
Measure
Dependency is necessary for functionality
Dependency is beneficial, but not absolutely necessary for
functionality
Dependency does not affect functionality
Dependency causes negative effects, but does not prevent
functionality
Dependency must be prevented to achieve functionality
+2
+1
0
-1
-2
Table 3-3 Design Dependency Criticality
Source: Sosa, Eppinger and Rowles, 2003 Identifying Modular and Integrative Systems and Their Impact on Design
Team Interactions
After the design dependency and criticality are defined, the data is integrated in a square design
interface matrix (Sosa, Eppinger and Rowles, 2000) known as design structure matrix.
Eventually an independent arrangement will be created for the development organization, and
lastly both matrices will be examined for conclusion and recommendation.
The research approach has been set up for this thesis so far; DSM meanings are characteristics
that have yet to be defined for the application of the organizational case study in this thesis.
3.4.1
Design Structure Matrix Definition
Nowadays multiple Scholars have defined the DSM as a tool that allows the identification of
interfaces in complex systems:
1. "A design structure matrix (DSM) is a two-dimensional matrix representation of the
structural or functional relationships of objects, variables, tasks or teams" (de Weck
and Lyneis, 2011).
2. "The design structure matrix (DSM) is a simple tool to perform both the analysis and
the management of complex systems. It enables the user to model, visualize, and
analyze the dependencies among the entities of any system and derive suggestions for
the improvement or synthesis of a system" (Home DSMweb.org, 2014).
57
3. "The DSM is a modeling tool used to represent the elements comprising a system and
their interactions; thereby highlighting the system's architecture" (Eppinger and
Browning, 2012).
The DSM is a square matrix (N 2 ) which graphically represents a system architecture. This
network modeling method maps the interaction of a set of N elements in a system (Eppinger and
Browning, 2012), see Figure 3-13.
The DSM can be applied in multiple fields, always when a complex system exists. Eppinger and
Browning in the book Design Structure Matrix Methods and Applications (2012) describe the
product architecture DSM for NASA's Mars Pathfinder project, organizational DSM for GM's
engine development, process architecture DSM for Real State development, etc.
x
x
x
x
X
x
x
X
X
x
1XI
I
Figure 3-13 Basic DSM example
Modified from Eppinger and Browning, 2012
The DSM application for different types of architectures has demonstrated the following
advantages according to Eppinger and Browning (2012):
58
0
Conciseness, large complex systems are compacted in the DSM.
" Visualization,
element relationships are highlighted; DSMs provide a view of
interactions in a product, process and organization architectures.
*
Intuitive Understanding, hierarchy and complexity are identifiable.
*
Analysis, component interactions of a system are visualized; it allows the use of the
system information on different analytical tools.
*
Flexibility, the DSM tool has the ability of being modified; new features can be added in
order to maximize potential.
In addition to the approach given to compare the architectures of the front end system and the
development organization for this thesis's case study, it is necessary to know the five step DSM
approach to architectural modeling and analysis developed by Eppinger and Browning (2012):
-
Decompose, the system is breaking down into a certain hierarchy level for analysis.
-
Identify, component relationship is established.
-
Analyze, components are re-accommodated for structural and pattern analysis.
-
Display, system is represented in the DSM to visualize key behaviors.
-
Improve, after DSM is analyzed, system enhancement takes place.
3.4.2
Types of DSM
In previous sections, we have mentioned that DSMs are applied to product, process and
organization architectures. According to Eppinger and Browning (2012), these architectures
correspond to the main type of DSM models. In addition, there is a fourth classification that
integrates the previous domains in a single matrix called multi-domain DSM.
59
The four types of DSMs are classified in three categories: static architecture, temporal flow and
multidomain (Eppinger and Browning, 2012). Figure 3-14 shows a decompositional view of the
DSM models; the three main categories are listed. Static architecture covers elements that exist
simultaneously; here product architecture and organizational architecture DSMs are included.
temporal flow represents systems that are impacted by time; here the main activity takes place in
the process architecture DSM. The multi-domain category incorporates more than one type of
DSM in the same matrix.
I
i
I
L
I
I
Subysem
I
I
Subprocesses
.... DepartmentsI
I
0omp0ent
I IndividualsI
Parameters
M_
Figure 3-14 Decompositional view of different Types of DSMs
Modifiedfrom Eppingerand Browning, 2012
During the development of the case study in this thesis, a new proposal DSM type emerged. It
has been called Multi-dimensional Embedded Matrix (MDEM). Multi-dimensional DSMs
include more than one type of DSM, and they are represented in a single DSM matrix denoted as
60
Multidomain Design Matrix (MDM). However, they are placed in different areas of the matrix
space. In addition clusters are made separately. The MDM in Figure 3-15 contains product,
organization and process DSMs overlaid in a single matrix.
A see
sessio
uspige
COMPWWF"nt
aWenaft
-
-waf
Poob to-
Figure 3-15 Multidomain MDM
Source: Eppinger and Browning, 2012 Design Structure Matrix Methods and Applications
3.4.2.1
Multi-dimensional Embedded Matrix (MDEM)
A Multi-dimensional Embedded Matrix represents more than one type of DSM overlaid in a
single matrix, which compares (for the CD-car case study) the product and organizational
architectures similar to the alignment matrix explained by Sosa, Eppinger and Rowles (2007).
However, the MDEM in Figure3-16 shows the re-arranged organizational structure based upon
the optimization of the product architecture. This means that the clustering analyses to get new
organizational architecture DSMs were done having both product and original team structure in a
single DSM at the same time; improvement of product architecture DSM configured the
61
organizational architecture DSM. In other words, the original organizational architecture DSM
and the proposed organizational architecture DSMs for this thesis were embedded in the product
architecture of the system. The embedded information allows the organization to be restructured
according to the product.
$root
m
e-z
a
r
dC
edSafely PledPro
F
Organizational
Architecture DSM
desr
(Colors)
rcesGnrto
3V.hS
-
hrchitecture DSM oderUto
Shock Tower
prackod
Sash sHaeld(N
Panel
Leal' screen
de
m es
er ts
Rlocker
COVA
Side
1Non contact
J2 Contact
Daily
Weekly
BoySide
-4-
Hng"
Z
Ftrnder
2AMonthly
2
Backet
Ehtg
Gap Hidlr (side
Hood
Grill
shi
Never
11
1
n
Rainforcement-
(GO
12=
2
2
Latch
_4
3
-
HodSeal
Elol ster
lLower Vent
ISide Marker LgK1
Figure 3-16 Multi-dimensional Embedded Matrix
The scope of this thesis did not allow the generations of additional. algorithms to replicate the
embedded DSMs. Clustering analyses were done utilizing commercial software but embedded
iterations were done by hand. Further explanation of multi -dimensional embedded matrix will be
described in chapter 4.
3.4.3
DSM Process Generation
In order to illustrate how a product architecture DSM is generated, Eppinger and Browning
(2012) have provided different elements to consider while creating these types of DSMs:
62
" Boundaries, selection of components within a boundary are incorporated into the DSM
in order to define the scope of the system.
" Interaction types, different kinds of component dependencies are considered: spatial,
structure, energy, material and information (Pimmler and Eppinger, 1994).
*
Interaction strengths, certain weight is added for each interaction; it may include
numerical values or symbols that reveal a degree of component strength relationship.
" Symmetry, typically component interaction occurs in two ways: having a spatial
dependency, component X interacts with component Y and vice versa. One way
interaction may happen: hood close/open sensor needs a signal from the latch system to
work, whereas the latch mechanism does not.
" Granularity, refers to the level of model component decomposition. Manageable DSMs
are typically compounded between 20 and 50 elements. The model can be enriched with
additional components based on the purpose of the DSM.
*
Identifying iterations, achieved by utilizing system documentation or specifications.
However, it is recommended to establish a dialog with subject matter experts to populate
interactions into the model.
At the same time, these authors have summarized in Table 3-4 criteria for successful DSM:
IIModels have a clear purpose iI
Models use the appropriate amount of detail for the intended purpose I
Modelers have access to enough knowledge or experience of the system I
f DSM is a living model, it can be improved with latest knowledge I
IIDSMs results in the emergence of otherwise latent knowledge 1j
Table 3-4 Criteria for Successful DSMs
Source: Eppinger and Browning, 2012 Design Structure Matrix Methods and Applications
63
K
3.4.4
Product Architecture DSM Application
A simple example is given by the analysis of the product architecture of a generic hybrid car
system. Figure3-17 shows a decompositional view of the hybrid car. It has been decomposed to
the second level in order to keep 13 main subsystems for analysis.
Hybrid Car
System
HAC
System
Fuel
Systems
Body in White
Cystum
Batterm
SystemSSyste
System
*
Rear
Hybrid Car System
'
ABS Module
Body
FrontEnd
Mounting
System
Dash Body
Atkinson
Ain
coto
conditionin
system
controller g
pumps
r compressor engine
EcSystem
~cyclewtevaumegnri
crair
gasoline
pump
Engine Box
Body System
Electric
Engine
power
Control
steering
Module
Advance
Ion-lithium
battery pack
Ec-
High
Hybrid
Vbltage
transmnei
on
harness
Low
vatage
Harness
-tteBody
Side
Member
System
Boundary of Hybrid Car System
Figure 3-17 Hybrid Car Decompositional View
Source: Shefali, Chaudhar',Reves and Cuata, 2013 System Architecture, Opportunity Set #1
The known interactions between components are represented in the boundary diagram from
Figure 3-18; the interactions represented in this illustration are spatial kind, which means that the
product links indicate physical adjacency between components. For example, the electric water
pump is plugged by the low voltage harness; both components are assembled together to deliver
a specific function.
Moreover, the map of the hybrid components incorporates external subsystems that are strictly
related to the architecture study; the type of dependencies is spatial as well.
64
Member
Body
SystemBdyysm
Auxiliar
S
Steering
ABS
Module
HVAC
System
Battery
my
System
IElectric
Colum
System
power
teering
Enin
compressor
-Control
Module
Engine Box
to
Body System
Rear
Sys
High
Ln-lithium
Body
battery
pack
tm
Regene
rative
braking
Aod
irnn
Electric
Vacuum
pumps
tisn
Voltage
cycle
Harness
gasoline
invgrne
-Voltage
Electric
syseter
harness
contr
(DC
t
erwaterAC)pump
HybridColn
Chas
L ---
- --
-.-
- ---
transmission
s
Radiator
.(Transaxle)
- -
Hybrid System Boundary of a Car
- - ---
--
- --
--
- --
- --
--
--
--
---
Mout
System
All links indicateSpatialDependency
Figure 3-18 Hybrid System Boundary of a Car
Source: Shefali, Chaudhary, Reyes and Cuata, 2013 System Architecture, Opportunity Set #1
The previous boundary diagram represents the high level interactions of the system; it was built
utilizing interface specifications from the hybrid system team at Ford. Furthermore, the data
collection was enriched through interviews with technical experts at the organization.
The hybrid system of a car is represented in the DSM model from Figure 3-19. The subsystem is
constituted by 24 components. Interactions are represented in a square matrix of 24 x 24.
The concept of operations in the matrix is related to the electrical process of the hybrid system
function as shown in Figure 3-17. It is supported by the electrical interaction clusters from the
The process starts with the ignition of the system; the electrical power is
distributed through high/low voltage harnesses in order to feed the control unit for monitoring of
speed and subsequently activation or deactivation of the gasoline engine. When the gasoline
partitioned DSM.
65
engine is working, the transmission/transaxle transforms the mechanical energy into electrical
power in order to charge the battery pack. At the same time, and during breaking, the kinetic
energy is converted into electrical power to charge the battery pack.
On the other hand, when the gasoline engine is deactivated, the battery pack supplies power
through the high/low voltage harnesses in order to activate the transaxle (electric motor) for
vehicle motion. In parallel, the electrical power is converted from DC to AC in order to enable
electric pumps to cool the battery pack. Gas depressurization is generated during the breaking
process by pressurizing water to cool gasoline engine (Shefali, Chaudhary, Reyes and Cuata,
2013).
0)
Nm
1
Coolng Radihor
2
I.e.Contr
P on.ogoang
5
_Erigmecontrlcd
o
Advncon-Udgawn
8
Electr.c wae.r pw"
9
High vltage
ectic
3
4
5
6
17
i
1s
1
6
bery~npc
1
4
1 16
17
IS 11
20
2
22
23
24
0
T
0e
0
16
41 10
0
.e
e~0
to'
0
*i
.0
harness
@7e
to
obCoV-
11
Hybrdlr.mss.io.
12
Ragenerabng
13
Lo
14
CO....
14
15
AS Modie system
15
16
Fe.system
16
17
HVAC System
.
*
ta
braking
12
..
13
. tage
1
2
4
.or
l~e
7
10
2
2
lecmpow,..song
A
1
-
3
ry
0
1,
S.erngCot
19
Atooary battery
19
20
Rom Body
20
21
Front
22
Dash body
22
23
hog.. boo body
23
24
Sde.mmber body
24
end Mounting
21
-7
0
40
4
0
*
t J
~11
18
j@
010
*
0~L
*
0
,
I
K:
4
'@
Figure 3-19 Hybrid System DSM model
Source: Shefali, Chaudhary, Reves and Cuata, 2013 System Architecture, Opportunity Set #5
3.4.5
Clustering Analysis
The purpose of clustering DSM is the allocation of N component to M clusters in order to
minimize the number and strength of interactions outside the cluster and minimize the size of
cluster through the utilization of diverse objective functions (Eppinger and Browning, 2012).
Although I am not mentioning additional information related to clustering objective functions
66
due to project scope; here are main considerations for clustering analysis per Eppinger and
Browning (2012) theory:
-
Number of clusters, there is no restriction for the number of clusters in the DSM;
however, it is recommended to develop different solutions for comparison analysis.
-
Clusters size, single component cluster is allowed; however, cluster max component
should be constrained to define a particular size.
-
Overlapping clusters, according to the purpose of the clustering DSM,
cross
membership in the clusters is allowed.
-
Interaction types, according to the component dependency, clustering may result in
different number of clusters due to the dependency level.
-
Integrating elements, refers to those components in the DSM model that stayed out of
the clusters; they typically have interactions with different components. The integrative
components serve as collective functions.
-
Manual clustering, accommodation of matrix columns and rows can be done manually;
it is useful for sensitive analysis around solutions proposed by clustering algorithms.
-
Multiple clustering solutions, recommended to generate different cluster solutions for
interpretation and analysis to accept an optimal result.
The DSM has been partitioned and represented in Figure 3-20. Notice that three main clusters
emerged: electrical, steering and supporting systems. The clusters re-assemble the way
automotive companies break down the vehicle system by commodities such as electrical, body
exterior, chassis, powertrain, etc. Since all the system analysis was not made for the entire
vehicle system but just for the hybrid system of a car, the clusters created by the DSM seem
logical. Specific component groups with strong interactions were identified. In the first cluster
the wiring, engine, transaxle, radiator and other electrical components were grouped. A second
cluster for steering components was created. A third cluster contains most of the support systems
67
such as the body white components, HVAC subsystem and brakes (Shefali, Chaudhary, Reyes
and Cuata, 2013).
19 Aeiwfr bory
I
9 40g VON"ag
4
1
.Ar
conor
heme
.p
23 Ensne bmx
b ody
10 Eletri
ptW
Soucesi1Frot
16
e,
\ww
a0
e Architeture,ei S
B etoersur5
23
urmn
F--l y-teee
:
Fiur 3-20Cluterd HbridSysem
F17r 3-20 CSystere
Sou2e Sheahi ChuhrRysan
SM
oe
HyrdSytmDS
ue,2*
ode
yte
rhtcue
pruiySt#
68
Chapter 4 - Analyzing the CD-Car Front End System Case Study
"Coming together is a beginning; keeping together is progress; working together is success"
Henry Ford
As a preamble for this section, it is necessary to reflect upon the complexity of the automobile
frond end system. It integrates more than 30 subsystems that deliver various functions. For
example, lighting, front crash absorption, cooling, engine protection and vehicle appearance. The
answer will be provided by analyzing the organizational architecture DSM models from the CDcar case study portrayed in chapter 2. The results of the analysis will dictate the optimal people
cluster interaction within the organization and the flow of communication between project teams.
These characteristics will impact in a positive way the effectiveness of the development for
future systems similar to the one analyzed in this thesis.
4.1 Organizational Architecture DSM Model
4.1.1
Organizational DSM Definitions
We begin with the definition of important concepts for organizational architecture DSMs:
1. Organization - "a network of people with a common purpose such as business unit
or a project developing, producing, selling or supporting a product" (Eppinger and
Browning, 2012).
2. Organization Architecture - "structure of the organization. It groups people into
teams, departments or any other organizational unit" (Eppinger and Browning, 2012).
3. Organizational Architecture DSM - "mapping of network of interactions among
the people within the organization" (Eppinger and Browning, 2012).
69
4. Interactions - "relationship among different units in the organization. It is focused
on information flow iterations: formal or informal, peer to peer communication such
as email, face to face discussion, group meetings, etc. Other interactions are
relationships of authority, responsibility, accountability, contractual obligations, etc."
(Eppinger and Browning, 2012).
5. Cluster - "a larger organizational such as department, team, or group of teams
suggested by analyzing the organization architecture DSM" (Eppinger and Browning,
2012).
6. Integrative Mechanisms -
"type of work coordination and communication
facilitated across organizational units" (Eppinger and Browning, 2012).
Sosa, Eppinger and Rowles in the paper Are Your Engineers Talking to One Another When They
Should? (2007) have explained how DSM helps managers to identify failures in communication
and deficiencies while unplanned technical communication occurs between project teams.
They start the analysis of previous condition by identifying component interfaces in a design
interface matrix of the system under development. This model represents the component
dependencies required to achieve specific functions. Then technical interaction teams are
recorded in a team interaction matrix, expected interactions are included. This matrix shows that
specific information/communication is required between teams. Both matrices are overlaid in
order to create a new model named as alignment matrix. The new matrix in Figure 4-1 it can be
seen that there is coincidence in some team interfaces compared to design interactions. On the
other hand, there are also mismatches in the alignment matrix. These are characterized in two
types: a) unattended interface, this occurs when the interaction is identified in the design but not
followed by the team; b) unidentified interface, team interaction takes place but it is not
highlighted in the design interactions.
Previous mismatches occur due to product and organizational factors: organizational boundaries,
lack of interface criticality, use of indirect communication channels, indirectly transfer of
communication, carryover interfaces and use of interface standardizations (Sosa, Eppinger and
Rowles, 2007).
70
Aligament Matrix Key
Design Interface Matrix
Matcbed intedfece: design
Providing components
BC
System
Arcitects'I
D
InputK
C
C
A
Team Interaction
D
8
BC
D
Uiidenmiied
A
h.5
D
interface: team
interaction that takes place
or is expected to take place
without a corresponding design
interface identified by system
architects
-
B
A
Lack of interdependuce:
B
C
components that do not share
an interface or involve design
team interactions
,
-
1D
-
Input
detennine tecinical
interactions teams
ha had, are having,
or expect to have
Matrix
Providing teams
A B
Design
interface identified by system
architects that lacks corresponding team interaction
Providing component teams
a
Teams'
Unattuaded inteface: design
Alignment Mabix
-
identify technical
interfaces between
components
interface that is matched by
an actual or expected team
interaction
Component A depends
on component D
Team C requests
information from
team 0
F
INot applicable
Figure 4-1 Identification of design and communication interfaces
Source: Sosa, Eppingerand Rowles, 2007 Are Your Engineers Talking to One Another When They Should?
Similarly to the product architecture DSM, Eppinger and Browning (2012) explains that the
organizational architecture DSM compiles different elements to consider when designing the
network model; these stipulations are applied to the CD-car front end system case study as
follows:
Granularity, refers to the level of decomposition of the organization typically done at
team or individual levels. For the CD-car case study, the organization has been
decomposed to the individual level; this means that each component in the boundary
diagram from Figure2-5 is designed by a single engineer in the project team.
*
Data Collection, the case study compiles the frequency of communication between
engineers of the project team. For instance, the organization interaction has been denoted
with a dot; the presence of a dot indicates that an interaction exists whereas a blank space
indicates no interaction between component teams.
71
"
Symmetry, in most of the organization interactions, the flow of communications was bidirectional; however, the data collected represents that in some of the component teams
the information flow occurs in one way and at different frequencies.
*
Accuracy, interactions in the DSM should typically represent communication both ways
with similar frequencies. That did not happen in some interactions of the CD-car project;
for this kind of cases; miscommunication reasons were discussed with component teams.
As an example, the fender engineer used to manage daily meetings and daily email
notifications with the gap hider engineer in order to define the attachment strategy of the
plastic part to the sheet metal. However, the gap hider engineer attended just weekly
meetings; emails were replied to weekly most of the time.
*
Representing Interactions, when there is an interaction between component teams,
frequency has been established with three measurements: daily (large size dot), weekly
(medium size dot) and monthly (small size dot). In addition, the product architecture of
the front end system has dependencies of adjacency; they are represented with yellow
color for non-contact interfaces and red color for contact interfaces (or high level
dependency). No color nor dot means that there is no interface between components, see
Figure4-2.
I*
Daily
Weekly
Monthly
Never
Non-Contact Interface
Contact Interface
Figure 4-2 Frequency of communication and product dependency nomenclature
*
Dynamics, the CD-car project represents a static view of the organization. The interviews
conducted with the project engineers were allocated for the three main stages in the
product development process at Ford. Afterwards, the average of frequency was
calculated to build the organization architecture DSM models.
72
4.1.2
Application Case: CD-Car Front End System
The node link diagram shown in Figure 4-3 represents a communication network that the CD-car
front end system team established during the development of the project; the arrows represent the
direction of flow of communication, the arrow weight is meaningless for this example. It is
clearly seen from the figure that there is a complex system of communication among this
organization. However neither the structure of the organization or the organizational units are
visible. Both set the flow of information to effectively develop the front end system of the
vehicle.
Figure 4-3 CD-car project team communication network
The lack of understanding on how engineers should interact in the structure of the organization
of the case study resulted in deficiencies on the design. For example, during the design phase I
(Figure 2-9) some component teams such as gap hider, splash shield and hood seal were not
73
incorporated into the project team. The consequence was a delay in the delivery of the
preliminary front end system architecture.
The application of the organizational architecture DSM for the CD-car study was intended to
satisfy the following areas of opportunity: identify gaps in communication among cross
functional system teams, enhance the product development process by adding organizational
DSM analysis into the failure mode avoidance framework, and ultimately to improve human
capital capabilities in attracting further "top hat" developments to the FoM organization.
4.1.3
Data Collection Process
In chapter 2, the decomposition level of the CD-car front end system was explained. It is
integrated by 28 main components, see Table 2-1 for complete list of components. The type of
dependency identified in the system was spatial: contact and non-contact interfaces. These
interfaces were then mapped in a boundary diagram, external interfaces were also incorporated
as shown in Figure 2-5 in order to end with 35 elements for analysis.
The information that is contained in the boundary diagram was translated into the product
architecture DSM displayed in Figure 4-4. The boundary diagram and product DSM were built
using the generic system design specification from the three main subsystems of the front end
system referred in chapter 2 (body structure, front end module and exterior ornamentation). In
addition, critical interactions were discussed with subject matter technical experts within Ford.
The result was a product DSM with four clusters which incorporated most of the strong
interactions (contact interfaces) in the system.
Similarly, the organizational architecture DSM was built through data collected from the project
team members. To achieve data collection, The interview template tool developed by the MIT
Research DSM Team (1999) was used for DSM data collection (Home DSMweb.org, 2014)
shown in Appendix A.
All the team components were listed based on the front end boundary diagram. Focusing on
information as interaction type, interviews were conducted with each component engineer in
order to identify the frequency of exchanging technical knowledge during the development of the
74
...........
project, strength of the interaction and expected transfer of information from different
component engineers. Once all the data was filled out into the Interview tool for DSM data
collection, the generation of a communication data set DSM shown in Figure 4-5 was the
baseline for the analysis of the organization structure.
4.1.4
Product and Organizational Architecture Models
The product DSM in Figure 4-4 represents the design interaction of three main subsystems from
the front end system with spatial dependencies. For example, in the cluster called body
structures, the fender system has a dependency of contact with the body side (fender is attached
to the body side). This condition was designed in order to keep the fender in a unique position on
the vehicle. Although there may be additional geometric features in the fender to allow
alignment to surrounding components (e.g. door) and meet fit and finish requirements; that detail
of design to keep this thesis within scope is not mentioned.
The product DSM signifies as baseline for comparison against the organizational DSM.
Following Sosa, Eppinger and Rowles (2007) approach, the purpose of the product DSM is to
identify first technical interfaces between components, and subsequently identification of
mismatches between design and team interactions.
On the other hand, the communication data set DSM in Figure4-5 represents the communication
flow of 339 interactions that exists in the project team. It also shows how frequently the
component teams interact with each other. For example, the bolster and the grill opening
reinforcement engineers used to interact daily; their interaction is represented with a large dot.
Also noted is that the flow of communication between those component teams was reciprocal
due to the interface symmetry shown in the row data DSM.
75
Front End System product DSM
13 20i 2
20
27
28
-
Front End
Module
23
24
X
a
U
N
I
25
70
Nt
N
N
N
N
N
N
N
Body
Structures
N
N
NR
-0
N
N
N
N
N
N
N
N
N
N
U
N
N
N
N
N
N
N
Exterior
Ornamentation
W
N
N N RN N N N N N N N N R N RN N N N
N
N
N
N
N
N
N
N
N
N
N
N
Non-Contact Interface
Contact Interface
N
N
N
N
N
N
N
N N
N R
N
N N
N N
N
"
"
SN
N
N
Info Sharing
Figure 4-4 Front End System product DSM
At this point the data illustrated in the preliminary DSM does not provide additional information
in terms of the structure of the organization nor mismatches against the product architecture.
Therefore, the next step for the analysis of the case study is to re-accommodate interfaces of each
component team in order to match the actual front end system team structure utilized during the
development of the CD-car project.
76
Team Communication data set DSM
1 2
14
s000000
0
0
-.
*
0
0.-..
*-
0
0
-
-
.
i
j
WeekIy
-Ner
-
-0
-
6-
-
0
0-.0
-
0
-
*
-
-
-
-.
0
0
0
-0-00
-
30
.312
-* 00 . -
S
*
55*
-0
-
-
-
-
000 --
"
28
S
*
-0
*0-
--
0
-
*0
05
.0000-5
00s
-
s
27
0-S.-
--
0
0
*
-
-
0..
.
5*-
*
060
-
-
.
* ..
-
0
-0
*
@0
-0
-
-
-.
-
*
-
0
-
*0
-
--.--
0S
.
*
- . -
-
ot.
-
-
0e
S. -
-
-
*
e- ---
60-.-
0
--.
-
-
--
-
-
-*
--.
*
33
5-
*"
-0-
34
3s
Figure 4-5 Team Communication Data Set DSM
The organizational DSM illustrated in Figure 4-6 contains the original front end system team
structure that developed the CD-car project. The teams were grouped according to the PMT 1000
of this program. Here transfer of technical communication flows from the team in row i to the
team in column j; note that for the development of this thesis the DSM convention was used with
inputs in rows (IR) and outputs in columns. The structure of the team is a departmental
organization integrated by four clusters: sheet metal hood, body exterior ornamentation, sheet
metal fender and front end module (FEM).
77
Original Front End System team structure
2 1 3 4 j 5 12 201
0-Weekly
I
1 Hood
3
4
FlyerEl mBumpei
StopBumperSheet
Metal"
Monthly'''
Never
Hood
Le4-6
ExteriorEndS"ste"
Oi
13 F t:nd11 Dpjash
17 FR' '-Jr FAnel
16
roduteog
14trixshown
sil
24
F,:, Im
26
28
LowpivWnr
Bcd-t-r
33
SzfetPedPro--
re
Fenderli
m
i
t
it
-
i
Front End
Module0
-
--
--
Wo:-k
c
sen
ham-
itrced h
te a
N-VH
-
35
Metal
10Sheet
-
le~prin
30 Crth
sI
-......
ta
Pnamnentation
21 Headlamp
22 Gie
28
FronBody
.
,32 Fin ,n-e
34 Purchazing
.
.
.
.
.
.
.
.
.
.
.
.
.
10
F
-
120 Lnqnch
Figure 4-6 Original Front End System team structure
The product DSM and the original team structure DSM have been overlaid to generate a new
DSM called alignment matrix shown in Figure 4-8. In that matrix, there are interfaces that the
original team structure matched to the product architecture. They have been highlighted in purple
with the I symbol. It can be seen that many interfaces matched; however, there are mismatches
in the matrix, as well. For instance, the mismatches were differentiated in two types:
a) Unattended interface. Highlighted in red with the X symbol, here the original team
structure did not transfer information with other team components whereas the product
architecture indicated that an interface exists. For example, the splash shield engineer did
not establish any communication to the fender engineer. The transfer of information
78
occurred in one direction, from the fender to the splash shield. On the product
architecture, this interface indicated two directional dependencies. So, why the splash
shield engineer did not contact the other component engineer? According to Sosa,
Eppinger and Rowles (2007), mismatches occur due to product and organizational factors
such as carry over interface which is the case of the previous example.
Based on the accuracy caveat considered for organizational architecture DSM, during
interviews with the front end system engineers, the splash shield engineer was asked why
he did not create any dialog with the fender engineer. He responded with the statement
that the splash shield to fender interface was a carryover condition. On the other hand, the
same question was made to the fender engineer. He answered indicating that the fender
design was changing in geometry to meet functional requirements (e.g. dings and dents)
and materials specification. The latest change would affect the thickness of the sheet
metal and consequently the interface with the splash shield. New attachment points may
be required or simply, the push pin to attach the shield to the fender may change to
overcome the variation of sheet metal thickness.
b) Unidentified interface. These are highlighted in navy blue color with the 0 symbol. The
interface means that a team interaction exists from the organizational architecture.
Nevertheless, the product DSM does not indicate such conditions. For example, flow of
communication took place between fascia and GOR interface; the reason lies in the fact
that the product architecture is a standardized tool. For this example, a new attachment
strategy from the fascia to the GOR was implemented; this induced unplanned
communication. Another reason of unplanned communication lies in the fact that the CDcar project team was not enough experienced (average of experience 6.2 years) to
understand to whom they should exchange information.
79
CD-Car Project Alignment Matrix
2 1
2
HDd
3
Insj r
Unattended Intetface
Unidentifiedlintetface
Matched Interface
Not Applicable
Lack of Dependency
1 H,,d
3 --r pDumper
4 J& rA Fump-
5 iFi 7an: h
'
12 L
11
20
L
7
261
2
:33
-
n
7
udio
weigE-
P
Tam
.
SyeTaSrcr
-d
rin
F29r
2the
-rreAgeMd
RstadPps
CD-car prjc ea.I
4-7 CD-car prnec
iur
byhaCvinag difent expertise Figure 4-
-,th
Alignent
rqecylvlofcmuiato
et croent
eneesf
atri
a
dddfo
frnatien systded
the original team structure matrix (daily, weekly or monthly). In a separate column,
communication instruments were added for three main channels: email, phone/webex and face to
face interaction. Also the component team location within the Ford PD organization was
integrated. Finally, the technical maturity data was gathered from project engineers; it was
combined with the previous information to assess the impact in the structure of the organization
by having different expertise from different component engineers of the front end system.
80
1. Communication Frequency. In a previous section, many of the organizational interfaces
matched the product architecture of the front end system; those interactions with high
level of frequency (daily and weekly) match the dependencies of contact from the
product architecture. However, there are many other unattended and unidentified
interfaces that were generated from the organizational architecture.
The model
incorporates 11 unattended interfaces located in the main component team cluster and 53
in the program integration cluster; in Table 4-1 a summary of alignment matrix counts
has been provided for more detail. Another characteristic noticed is that most of the
unplanned communication interactions have a monthly frequency. Lastly, a total of 94
interactions including matched interfaces and unidentified interfaces to the product
architecture were left out of the cluster teams. These gaps in communication will be
enhanced by a series of clustering analyses of the overlaid product and organizational
matrices.
Zo
NO
0
PI
11
53
X - Unattended
NO
1:
CT
'YES
122
67
CT
Pi
823
Lack of Dependency
63
86
I- Matched
0- Unidentified
YES
NO
PRODUCT
Table 4-1 Count of Design and Organization Interfaces
Modified from Sosa, Eppinger and Rowles, 2004
2. Instrument for Communication. The main instruments used by the component
engineers were: email, phone/webex and face to face interaction. The data collected from
the component engineers suggests that the transfer of information in the CD-car project
was conducted through email at 52.8% utilization on a daily basis, through phone/webex
81
at 28.6% utilization on a weekly basis and through physical interaction only at 18.5%
utilization on a monthly basis.
3. Front End Team Location. In terms of the workplace, the clusters are located in two
different regions in North America (USA and Mexico), segregated in three different
buildings within the PD office. Ford USA is the region where most of the component
engineers were located, 54.2%. FoM captured about 45.7% of the team. The map in
Figure4-7 shows how the front end system component teams are spread along different
regions and locations. For those clusters located in the FoM building, the component
teams are distributed in different building floors. The arrangement of the team structure
makes more difficult the transfer of technical communication due to the distance (Allen
and Henn, 2007). However, there are remote communication tools such as email and
phone/webex to overcome this constraint; in other cases the FoM management has
allowed cross regional travel in order to personally interface with peers and improve the
transfer of technical communication. This is a challenge driven by the design of global
products and the decentralization of the product development organization as strategy to
optimize resources in the company.
Ford USA
Building #1
Building #2
d~h
a
FbM
Floor #1
Floor#2
Floor #3
Building #3
00o
Sheet Metal Hood
C Exterior Ornamentation
*Sheet
0
Metal Fender
J Program Integration
Front End Module
Figure 4-8 Front End System team location map
82
4. Technical Maturity Data. The degree of.expertise from each component engineer was
surveyed, and years of experience within Ford, as well. The engineer experience has been
divided into four different levels from the least to the most experienced:
a. Build, the engineer is learning company's processes, performs basics routine
tasks but needs help with more complex situation, contributes with supervision or
under direction of others. Average component engineers in the CD-car project
have reached 96% of the total build level.
b. Apply,
engineers
increase
in
technical
ability,
handle
complex
tasks
independently, work independently and deliver targeted results, engage team in
order to get things done and implement recommendations. Component engineers
in the CD-car project are at 90% of the apply scale.
c. Leverage, complex work in a wide variety of situations including novel and
unique are performed by engineers; engineers contribute to cross organizations,
engage stakeholders across the organization and enterprise to get input and buyin, contribute to the development of standards and implement standards. The team
in the CD-car project is at 75% of expertise.
d. Master, engineers serve as functional mentor in the competency area, perform the
most complex
work,
develop
and implement
innovative
solutions and
interventions to address complex, novel and unique situations; stimulate new
technical and functional perspectives through ideas and knowledge. Engineers are
prepared to develop standards and models for competency area, research and
analyze internal and external trends. Finally, they influence the organization
assessing external trends and the organizational implications. The CD-car team is
prepared at 42% of this competence.
83
Finally, the data indicates that 32% of the project team members have an
experience level of build, 30% of the group is located at apply degree; 25% is at
leverage level whereas only 14% have achieved the master level of experience.
The utilization of partitioning algorithms especially clustering analyses helped us to rearrange
the interaction network from the original front end team structure matrix in Figure 4-6. The
purpose of clustering analysis is to reduce the 94 interactions outside the four main clusters.
In the following section, four different system team structure proposals are provided, which
represent the evolution and refinement of the optimal organizational architecture for the front
end system team. Component teams are compressed in the new structure of the clusters; high
level frequency of interfaces is now contained in the clusters so the sizes of the new structure
teams are larger.
84
CD-Car Project Leveraged Alignment Matrix
2 I
4
2
5
1220
I 1
6
0 6
7
7
4
3
63
1
131
5
11
1
17 1614 151
7'1
4-1
3
6'2
3
2
2 2
2
2
5 2
2
2
6:2
2
3
7 3
2
3
3
0,3
3
3
~
4
2 3
I
t
-ace
to
webex Face
6
1
7
X
3
1
2
6
X
3
2
6
X
3
1
1
2
6
3
2
2
7
20
3
3
0
6
6
3
1
1
5
3
1
3
7
X
Not Appicabe
3
2
2
7
X
Lock dDependency
3
1
2
6
X
3
2
1
6
3
1
0
4
X
3
Daily
3
3
1
7
X
2
Wooedy
3
2
0
5
3
1
1
5
X
I
0
M"A*~
No ar
3
1
1
5
X
3
1
2
6
X
3
1
0
4
X
3
2
1
6
X
3
3
1
7
X
3
3
1
7
X
U
17
CL16
21
22
U
U
Unattende4 mtedace
Matched InMe0ce
X
X
X
2
2
7
X
1
5
X
24
3
1
5
X
26
3
1
1
1
1
5
X
28
3
2
1
6
X
27
3
2
1
6
X
33
3
1
1
5
23
3
2
0
5
30
3
2
2
7
X
31
3
2
1
6
X
35
3
1
1
0
4
X
0
4
I
57
2*.64
0
38
4
MIS
S52.5
M
13.1
Unidemibed ktdbc"
X
3
=
Ul
X
3
3
SMoft"
X
25
23
3
00
Daily
1
3
13
S
9
X
2
3
U
10
S
USA
3
2
f*
Io~Ic~cto
VeiF.MUSA
X
X
X
X
16
45.7
17
43
2
5.71
System Team Structure - Proposal 1
4.1.5.1
Proposed System Team Structure 1
27
281
2
242
26
24
LO:erir
System
Tom 1
Mnhy
ee
Fglr
*
3*
22 0
18
4-10 F
End
System Tea Structrr - Proposa 1Sy4clusnters
94R ne
17
11
psaTe
ha
ern
7
1
Non-Contact Interface
Contact Interface
System
m
i
imple
T
4
F
e
Tir-
F0iQN '
lses
rpsl1(
emSrutr
gram-0FotEdSse
3cariH
Th
94rtea tion etoto
h
rommncaenedrreurmensefcivl.Weoto
o
ineatosaeicrae.I
20engineEesd
3ndntfe
.prrm
mies3
ns
ha3
ensm0fe
Thr1g
createed In the new
aif
h
pattoigagrths
e
-1.Fu
nFgr
marx h
numer
cuter; he nteaFiurs 4eft Font
cur
th prbe
eas
trctr
etpoes
orss-h
pn
hs
eiealsrqetddrn
ecieyt
ok
itgainta
tdvlp
tecssti
reactielytaif
work
progam
le rss h
efetiey Whntep.
6r reure et
kmuit Jed team
doo doiteraio
e2ier
tem
tedsystem
ftepo
prahe aietn
apeTwentepega
4yial
rgiafr
he
lSesfrm
ytmtasada
EdSem Tedm Sut
t
rmteoignlta
neatondt
andsengt
hs
eiealsrqetddrn
of ineato
rga
nerto
emwr
r
noprtdit
h
ur 2 A Prpoalt( clditerhas)
aate
tr
e
e
86
this solution is the clusters overlap; it represents cross membership in the system teams.
Nonetheless, there are still opportunities to integrate interfaces in more robust clusters. For
example, in the upper right portion of the DSM there are several interactions with high
frequency; this indicates a lot of overlaid between cluster 1 and 3 so this alternative is not
optimal (Eppinger and Reyes, 2014).
4.1.5.2
System Team Structure - Proposal 2
Proposed System Team Structure 2
1520i 27128126* 231 2425,22 211813 14 16. 17 11
20
8
7
6
5
4
3 12
2
1
25 30 31
323
34 35
EngIO
27 BeaurN
Jd
28
,r
SoE
26
15 10:
Lcwet
C-
--
e
Never
FoCmp
-
le Weekly
System Tem 1
Wrn
Non-Contact Interface
23 F.
24
-
IMonthly
ontact
Interface
Figure 4-11 Front End System Team Structure - Proposal 2 (3 clusters)
The second simulation obtained to optimize the structure of the organization is represented in
Figure 4-11. The clustering analysis generated three system teams with the same program
integration team. The size of the clusters is equilibrated meaning that there is a balance in the
project team. Cluster overlap is present like the previous DSM indicating that the system team 2
87
should also be working close to system team 1 and 3. This proposal reduced the number of
outside components to 65; most of the matched interactions to the product architecture are
incorporated in the clusters.
4.1.5.3
System Team Structure - Proposal 3
Utilizing the proposal with 3 clusters from the previous figure, notice that the hood engineer is
interacting with most of the other component teams; nevertheless it has not been classified in the
program integration team. Taking the essence of the program integration team but applied to the
component teams, in Figure 4-12 the incorporation of a component integration team is led by the
hood subsystem. Odd as this might sound this has been specified by the body exterior
management group at Ford USA that some vehicle subsystems should act as integrator due to the
large number of component interaction.
Proposed System Team Structure 3
13 2O 27'28.23'24 25 22 2
20 Enin
27
28
18 1
14 16 1
11 15 10
7 6
4312
3
35
Week
r
BE,-ut, -1,dBol.r
-
M nhl
System Tem 1
26 Los-_
23 F
24 Fo,
123331032
i
N
Component
m
Non-ContactInterface
ContactInterface
Figure 4-12 Front End System Team Structure - Proposal 3 (3 clusters and Component Integration)
88
4.1.5.4
System Team Structure - Proposal 4
MultI-Dlmentional Emnbedded Matrix
j,
M.
-n
L~trtwit
Rwcha..ing
Dein tudio
2
NVH
4~
Sa*_ Ped Pro
VehideOperahions
5
3
-
-
U.
Program
1 Integration
6
Craftsenship
Non contact
2 Contact
Wipers
Gas Strut
S
13
HoodIna ator
T
EngineCover
Shock Tower Bracket
Splshsehield
Non-class A
Component
Team
Rocker Panel
Ledw &ceen
cowsie
Body Sde
1
17
Hnges
-
Food
24
OvernsaBumpers
21
LHeadamp
Z,
Foa lavm
Product Architecture DSM
(Numbers)
11.1ump1w
GriI Opening Reiforcement (6FR
Fascie
Lower Vent
SdeMerkerUiht3
Unidentified Interface
Unattended Interface
Organizational Architecture
DSM (Colors)
15
Shotgun Bracket
e shield)
G iid
Hood Seal
BeauAV shield
LBosterN
Grill
o
-
-0
Fender
Daily
Weekly
Monthly
Neve
21
21
3
3
U
Class A Component
Team
U
U1
U
3:
3!
Figure 4-13 Front End System Team Structure - Proposal 4 (MDEM 2 clusters)
As a final point, the fourth organizational architecture DSM proposed to improve capabilities and
communication in the front end system team is represented in Figure 4-13. This is the multidimensional embedded matrix described earlier in chapter 3. Product DSM and organizational
DSM were partitioned together. The original structure team was set up in function of the product
design with the objective in mind of minimizing the number of clusters and incorporating most
of the interactions in the clusters. The results of this simulation were two system teams and one
program integration team. The first system team called non-class A component team now
incorporates elements from the sheet metal fender and body exterior ornamentation clusters from
the original team structure such as fender, hinges, wipers or shotgun bracket. While the second
system team named as class-A component team includes parts from the sheet metal hood and
front end module clusters; for example, hood, headlamp, grill or fascia.
89
The reorganization of the team shown in this matrix left only 8 component interactions out of the
cluster teams (including unattended interactions); the improvement in capturing outside
interactions into clusters was 91%. This means that 91% of technical communication
transmission will be taken into account. The mismatched (unidentified and unattended) interfaces
have been added to the DSM in Figure 4-13, they were marked by hand. Unplanned
communication is now captured in the team structure. Another finding is that both system teams
overlap; a dense group of component teams like the fender and hood locked the strict
relationship that exists between the two clusters.
Note that the new system teams are much larger. Although the larger teams captured most of the
uncontained interactions, large size groups create difficulties for organization and potential
delays in the program. Here the tradeoff is to have: a) smaller and manageable system teams
leaving important interactions outside the clusters or b) large system teams difficult to manage
but capturing most of the interactions during the development of the project. The decision might
be taken based on the program needs. For example, there are organizations that require a lot of
detail while developing a product; close transfer of technical communication among the whole
project team may be needed in order to guarantee the success of the product. On the other hand,
there are organizations that rely on the ability to quickly release a product; time is a limitation
that they may overcome by handling small project teams.
Having previous results in the MDEM, the proposal is to consider this matrix as the optimal team
structure framework for the front end system. As recommendation, additional clustering analyses
for the non-class A and class-A component teams are encouraged; future developments of front
end systems should be able to easily implement this framework; unplanned communication will
be transformed into planned tasks according to the program needs.
Figure 4-14 represents the evolution of the improvement in the number of component teams
outside the clusters for each DSM proposal. The original team structure had 94 interfaces outside
clusters; the first partitioning improved the condition to 72, second organizational proposal left
65, the third moved to 46. Finally, the fourth simulation reorganized the organization into two
clusters with 8 interactions outside the system teams.
90
4
74
Figure 4-14 Multiple Clustering Solution Summary
91
Chapter 5 - Conclusions and Recommendations
"I think that is the single best piece of advice: constantly think about how you could be doing
things better and questioningyourself"
Elon Musk
5.1 Summary of Results and Conclusions
The effectiveness to succeed in the development of the front end System CD-Car project highly
depends on the organizational architecture defined by the program team. Although the original
organization team structure for the case study integrated four main subsystem teams, the
arrangement was not the optimal; 94 cross functional interactions were not integrated in the
clusters. The data suggests that unplanned interactions at different levels of frequency may occur
along the development of the CD-car project.
Another characteristic
for successful projects are frequency and quality of technical
communication in the organization. Various critical dependencies from the product architecture
were expected at high frequency, daily and weekly at the most, in organizational team structure.
However, 32 product design interactions that matched component team interactions at high
levels of frequency were not considered as critical by the PMT group.
The effect of workplace communication has also played an important role in the quality of
communication. Team distribution among the two different PD offices was balanced; however,
such team segregation brought the use of erroneous channels of communication. For instance,
the spreading of CD-car project team members was half in USA and half in Mexico; the transfer
of technical knowledge was expected to be performed at least by phone/webex given the
complexity of information. Nevertheless, the distance was a major factor to reduce the
probability of interactive communication by using email. The high use of email has generated
unplanned interactions that were not considered in the product architecture of the front end
system. There were 45 unidentified interactions located out of the cluster teams and 18 additional
within the clusters. Once again emphasis must be put on the idea that during the development of
92
the CD-car project, the team communication was established via email approximately 53% on
daily basis.
On the other hand, low level of technical maturity from some of the front end system component
engineers reduced the number of interactions in the project stated from the product architecture
DSM. There were 11 unattended interactions that were critical for the success of the project. The
summary of data indicates that about two thirds of the CD-car project team are in the build and
apply maturity level; it is expected that an immature organization incurs incapability problems
during the development of a technical project.
Additionally, technical expertise for the development of the front end system impacted the
frequency in communication; the data illustrated in the alignment matrix suggests that
component engineers with working experience of no more than 6 years have communicated at a
frequency level of weekly and monthly for most of the component interfaces along the
development of the project.
The DSM is an effective network modeling tool that provides a clear picture of the relationships
that exist in complex systems. Organizational architecture DSM has important parameters that
help us to enhance the organization structure of a project. In the CD-car case study, the clustering
analysis brought four team structure proposals; the target of the partitioning simulations was to
incorporate most of the interaction external to the clusters into the actual clusters or new clusters.
In addition high frequency dependencies were expected to be inside these clusters. The result
was a new front end system team structure that can be taken as framework for future
development of the same vehicle system.
The framework consists of an organizational architecture DSM that incorporates two main
system team clusters; a third cluster is included to capture the program integration. The system
team clusters combines critical product design interfaces, frequency of communication
interactions, unattended interfaces and unidentified interfaces. The latest feature may be
aggregated as complement to the product architecture of the front end system. Unattended
interface can be highlighted as critical interfaces with weekly or daily frequency, according to
the expectation of the program team. The program integration team works in a more robust
manner given that unattended and unidentified interactions were found as well.
93
Based on the results found with the analysis conducted on the CD-car case study in this thesis,
the conclusions according the thesis objectives and premises will be described as follow:
*
The identification of gaps in communication among cross functional system teams was
certified by comparing the product architecture DSM and the original organizational
architecture DSM of the CD-Car project. The result was an alignment matrix that was
complemented later with component engineer's expertise data, physical location of
project team, communication channels and frequency level of communication.
" The improvement of human capital capabilities in attracting further "top hat"
developments to the FoM organization may not be visualized at this point. However, the
application of organizational DSMs brings to the workforce the benefit capabilities
enhancement by avoiding mismatched interfaces while exchanging technical information
with other project teams.
" Product interfaces are defined with a product architecture DSM; product systems are
developed by teams; therefore, organization DSMs can lead to the development of a
project having well organized system team structures. The development of a project can
be performed without an organizational DSM; however, the degree of success during the
development of a project is highly influenced by the optimal organizational team
structure. This organization architecture is achieved by utilizing DSMs. The front end
system framework has been portrayed in this thesis with a leveraged alignment matrix
DSM and a multi-dimensional embedded matrix which bring major benefits to the
company: identification of project clusters, mismatches in communication, team
communication
frequency,
channels to transfer information,
project
integration
interfaces, enhancement of innovation process and the overall improvement in the project
development.
" Development and implementation
of system team structures
can improve the
performance of a product team and the outcome of a project. Most of the component
engineer's interactions are accommodated in system team clusters, including mismatched
94
interfaces; this means that if a project team follows the new structure, there will be no
new unplanned interactions. In addition, the project team location has been aggregated to
the leveraged alignment matrix; there is a correlation in communication efficiencies
having the previous variable. The incorporation of the workplace parameters derives the
communication channel which highlights component teams' communication that the
program should pay more attention for the success of the project.
*
Structured communication among system team members can enhance personnel
capabilities by acquiring experience from cross functional interactions. There was not an
explicit outcome for this premise; nonetheless, the expectation is that regular
communication between project engineers will expand experience to certain team
members. The more communication, the more practice from the engineer on the product
that is being designed.
5.2 General Recommendations
5.2.1
Recommendations for FoM to Leverage the Capability of Human
Capital
Workplace has an effect on people's communication. When a project team is distributed
in the same facility of the PD organization, the transfer of technical and complex
information has to be established with personal contact (face to face). This is a prevention
mode to avoid miscommunication while developing a project.
o
Less "e-mail engineering", more personal contacts/meetings to solve and discuss
issues, more face to face meetings to update everyone on expectations/deadlines,
meetings minimize the need for chasing down e-mail status updates.
o
Personal contact builds relationships; building relationships facilitates transfer of
knowledge in the organization.
o
If you want documentation/record, publish brief minutes on agreements/next steps
after meetings.
95
o
Minimize wait on others, walk to the engineer cubicle to discuss.
It is important to have most of the project teams in the same location in order to prevent
excessive communication via email while transferring technical knowledge; it is highly
recommended the use of virtual communication tools such as phone or webex when
distance is a barrier in communication. Closely manage cross regional business travel
when physical interaction is the priority.
Engineer's technical maturity level affects the degree of communication in the
organization. In theory, the more experience, the more communication; high experienced
engineers (leverage level) know that they have to communicate with the team at certain
frequencies; whereas if the engineer is a novice (build or apply level), he won't know the
component teams he should interact with or the frequency level of communication while
developing a project.
During the early stages of the product development process, component engineers should
be provided with a guideline to develop a preliminary organizational DSM. This will
enable a set-up of proper communication channels in order to avoid lack of
communication,
miscommunication
and
unexpected
communication.
The
recommendation should be very useful for build and apply level engineers in the FoM
organization.
The framework developed for the front end system should be utilized as a generic tool
for:
a. Organization team structure diagnosis: it applies when the original team
structure was set up by the program management team; when deficiencies in
communication occur, there is a need to rearrange the organization to improve
the performance of the project.
b. Organization team structure definition: the defining phase of the product
development process, the program management team should initiate the
development of the organization structure alternative. This framework
96
incorporated both the alignment matrix with interaction and project team
indicators (leveraged alignment matrix) and the optimal front end system team
structure (MDEM).
Incorporate organizational architecture DSM into the failure mode avoidance process at
Ford; this is the missing link to integrate a robust development process of a complex
system within the company. The organizational DSM will enhance the flow of
information in component interfaces, additional noise factors may be contained in the
original development. Failure modes will be capture due to efficient interaction among
component teams.
The findings and framework were presented to the Ford USA engineering management;
they agreed that the organizational DSM models might add value to the company. DSMs
are useful to improve transfer of information within the organization; the framework
should fit within the Ford's processes to optimize communication during the
development of a project. Mark Garascia (Body Core Engineering Supervisor at Ford
USA) mentioned: "I think this is a nice model, the last week we were talking about
communication issues, inefficiencies that occur in projects and proposals to overcome
these problems, but how to implement this type of model in Ford? It is a difficult one".
According to Ford's management, understanding the organizational DSM is relatively
easy; however, incorporation in Ford is challenging. For instance, the management team
is interested to highlight the proposal in some forums such as Core Manager's Decision
Forum or Director's EMM meetings in the body group. On the other hand, processes and
standards development takes too much time. The proposal is to take a particular project to
get a different arrangement of a team. To start up, the implementation should be done in a
small application, small programs like an MCA or even smaller Ford organizations to
apply DSM structures. The management agreed that a pilot should be run in smaller
groups such as Ford of Mexico. Replication of the analysis from this thesis in order to
prove the concept for incorporation in a larger scale.
Although this information may be incorporated in the frameworks mentioned previously,
it is highly recommended to redefine the minimum level of communication frequency
97
while exchanging information given the criticality of the relationship from the product
architecture, and program needs.
Incorporate unidentified interfaces as complements to the front end system product
architecture. New component architectures or system innovation may be incorporated;
the team should be ready to avoid unexpected communication within the project team.
As a result from the DSM proposal 3 and according to statements from the body exterior
management, the recommendation to the FoM organization is the incorporation of a
liaison engineer per commodity group in order to act as component engineer integrator. It
will allow him to be part of all team interactions in order to prevent miscommunication,
facilitate and promote communication, capture missing links and avoid delays on
deliverables.
Lastly, in terms of workforce expertise, effective cross functional interactions enable
technical knowledge capacity. Inversely, more mature technical level (e.g. leverage)
enables better communication and interaction among team members of a project. This has
been correlated in the leveraged alignment matrix. Experience is acquired by practicing
the same task multiple times; it also can be achieved by interacting with subject matter
experts or while solving complex issues that leave important lessons learned. The
recommendation for FoM is to leverage build and apply engineers over in the Ford
assembly plants for a determined period of time. The idea is to link the product design
with the assembly process, operations, design for manufacturing and issue resolution. All
together to maximize the experience of engineers in preparations for the development of
complex products in the organization.
5.2.2
Recommendations for Future Research
As a final note, the analysis of the front end system CD-car case study was done for the detail
design phase of the product development process. The project is still ongoing. It is highly
recommended to continue applying the organizational architecture DSM in the subsequent
98
phases of the product development process: prototyping, testing and launching in order to ensure
the success of the project or to leave a precedent about organization behavior during the second
half of the product development process.
Additionally, the utilization of this thesis and application of organizational DSMs for other
vehicle subsystems may contribute to the improvement of communication in the organization.
Replicability of this research on similar or different vehicle subsystems may create awareness to
the company
for product development
improvement,
and human capital
capabilities
enhancement.
To finalize, MDEM models were prepared with a combination between manual clustering
analysis and commercial software tools for partitioning simulation. Due to time and scope of this
thesis, the development of new algorithms for clustering in multiple domains at the same time
was omitted. Therefore, for future research it is recommended to explore this modeling stream.
99
6 - Bibliography
Aguirre, A., (2008). Design of ProductDevelopment Systems. Massachusetts Institute of
Technology, System Design and Management Program, Cambridge, MA.
Allen, T., (1986). Organizationalstructure, information technology and R&D productivity. IEEE
Transactions on Engineering Management 33(4): 212-217.
Allen, T., and Henn, G., (2007). The Organizationand Architecture of Innovation: Managing the
Flow of Technology. Butterworth-Heinemann and Architectural Press, Burlington, MA.
Autoweek, (2012). Auto week editors' choice awardbest of the 2012 North American
InternationalAutoshow, autoweek.com
Rereieved September 18, 2014 from
http://autoweek.com/assets/pdf/CW7718811.6.PDF
Christensen, C., (1997). The Innovator's Dilemma: When New Technologies Cause Great Firms
to Fail. Harvard Business Review Press. Boston, MA.
Christensen, C., and Raynor, M., (2003). The Innovator's Solution: Creatingand Sustaining
Successful Growth. Harvard Business School Press. Boston, MA.
Crawley, E., (2013). Systems Architecture Lectures. Massachusetts Institute of Technology.
System Design and Management, IAP 2013, Cambridge, MA.
Dean, J., and Susman, G., (1989). Organizingfor ManufacturableDesign. Harvard Business
Review. Cambridge MA.
de Weck, 0., and Lyneis, J., (2011). Successfully Designing and Managing Complex Projects.
MIT Press, First Edition, Cambridge, MA.
Diaz, A., (2014). Evolved Technical Maturity Model. Communication Skills Meetings, Ford of
Mexico. Mexico, D.F.
Environmental Protection Agency, Office of Transportation and NHTSA USA Department of
Transportation, (2010). Environmental ProtectionAgency Fuel Economy Label. Literature
Review. PRR Inc.
Eppinger, S., and Browning, T., (2012). Design Structure Matrix Methods and Applications.
Engineering Systems Book, The MIT Press, Cambridge, MA. London, England.
Eppinger, S., and Reyes, R., (2014, December). Thesis Review. USA. (R. Reyes, Interviewer).
Feld, C., and Hatch, D., (2014). The Calloway Way. FG Press. USA.
100
Ford Speak, Internal Ford Network, (2014). Definitions and Concepts. Dearborn, MI.
Retrieved October 11, 2014 from
http://www.at.ford.com/Pages/default.aspx
Garascia, M., and Reyes, R., (2014). Thesis Review: OrganizationalDSM application.USA. (R.
Reyes, Interviewer).
Gebala, D., and Eppinger, S., (1991). Modelling the impact of organizationalstructure on design
lead time and product quality. MIT Press, WP# 3301-91-MS, USA.
Gulati, R., and Eppinger, S., (1996). The Coupling of Product architectureand Organizational
Structure Decisions. Working Paper 3906-96. Massachusetts Institute of Technology,Sloan
School of Management, Cambridge, MA.
Hayes, H., Steven, W., and Kim, C., (1988). Dynamic Manufacturng: Creatingthe Learning
Organization.The Free Press, New York.
Hoffman, Bryce G., (2012). American Icon, Allan Mulally and the fight to save Ford Motor
Company. Crown Business, New York, NY.
Home DSMweb.org, (2014). The Design Structure Matrix (DSM), dsmweb.org
Retrieved December 7, 2014, from
http://www.dsmweb.org/
INCOSE. (2011) Systems EngineeringHandbook V3.2. 1. San Diego, CA.
Joglekar, N., Yassine, A., Eppinger, S., and Whitney, D., (2001). Performanceof Coupled
ProductDevelopment Activities with a Deadline. Management Science, INFORM, Vol. 47,
No. 12, pp. 1605-1620.
Lopez, L., (2014). Incorporatingthe Innovation Process in a Product Development
Organization. Massachusetts Institute of Technology, System Design and Management
Program, Cambridge, MA.
Maier, M., and Rechtin, E., (2009). The Art of Systems Architecting. CRC Press, USA.
McCord, K., and Eppinger, S., (1993). Managing the IntegrationProblem in Concurrent
Engineering. MIT Sloan School of Management, WP# 3594-93-MSA, USA.
Morelli, M., and Eppinger, S., (1993). Evaluating Communicationsin Product Development
Organizations.Working Paper Number 3602-93. Massachusetts Institute of Technology,
Cambridge, MA.
Morelli, M., Eppinger, S., and Gulati, R., (1995). Predicting Technical Communication in
Product Development Organizations. MIT Sloan School of Management, WP#120-95,
USA.
101
Nelson, G., and Reyes, R.; (2014). Engieering Interview. USA. (R. Reyes, Interviewer).
Pimmler, T. and Eppinger, S., (1994). Integrationanalysis of product devompositions. ASME
Conference on design Theory and Methodology. Minneapolis, MN.
Qi Dong, (2002). Predictingand Managing System Interactionsat Early Phase of the Product
Development Process. Massachusetts Institute of Technology, Mechanical Engineering
Program, Cambridge, MA.
Reyes, R., (2014). The Flow of Communication in Space: The Body Exterior OrganizationCase.
Organizing for Innovative Product Development. Massachusetts Institute of Technology.
System Design and Management, Spring 2014, Cambridge, MA.
Saada Saar, S., and Hargrove, M., (2013). Leading with Conviction: Mastering the Nine Critical
Pillarsof IntegratedLeadership. Jossey-Bass Wiley, San Francisco, CA.
.
Saunders, T., Gao, J., and Shah, S., (2014). A case study to evaluate lean productdevelopment
practices in the global automotive industry. Int. J. Product Development, Vol. 19, Nos. 5/6,
pp. 3 0 7 - 3 2 7
Shefali, S., Chaudhary, A., Reyes, R., and Cuata, J., (2013). System Architecture, Opportunity
Set #1. Massachusetts Institute of Technology. System Design and Management, Fall 2013,
Cambridge, MA.
Shefali, S., Chaudhary, A., Reyes, R., and Cuata, J., (2013). System Architecture, Opportunity
Set #5. Massachusetts Institute of Technology. System Design and Management, Fall 2013,
Cambridge, MA.
Sosa, M., Eppinger, S., and Rowles, C., (2000). Understandingthe Effects of Product
Architecture on Technical Communication in ProductDevelopment Organizations.
Working Paper Number 4130. Massachusetts Institute of Technology, System Design and
Management Program, Cambridge, MA.
Sosa, M., Eppinger, S., and Rowles, C., (2003). Identifying Modular and Integrative Systems and
Their Impact on Design Team Interactions. Journal of Mechanical Design. 125(2), 240.
doi:10. 1115/1.1564074
Sosa, M., Eppinger, S., and Rowles, C., (2004). The Misalignment of ProductArchitecture and
OrganizationalStructure in Complex Product Development. Management Science, vol. 50,
no. 12, pp. 1674-1689.
Sosa, M., Eppinger, S., and Rowles, C., (2007). Are Your Engineers Talking to One Another
When They Should?. Harvard Business Review, vol. 85, no. 11, pp. 133-142.
-4-0
A ISIMON
111
F III, I R I , -Mmmww
,
102
Stone, M., (2009). 2010 Motor Trend Car of the Year: Ford Fusion, motortrend.com
Retrieved September 18, 2014, from
http://www.motortrend.com/oftheyear/car/1 12_1001_2010_motortrendcarofthe-yearf
ordfusion/
Tripathy, A., and Eppinger, S., (2013). Work Distributionfor Global ProductDevelopment
Organization. Product and Operations Management, Vol. 22, No. 6, pp. 1557-1575.
Ulrich, K., and Eppinger, S., (2012). Product Design and Development. Fifth Edition, McGraw-
Hill Higher Education. New York, NY.
Unger, D., and Eppinger, S., (2011). Improvingproduct development process design: a method
for managing informationflows, risks, and iterations. Journal of Engineering Design,
22(10), 689-699. doi: 10.1080/09544828.2010.524886
Womack, J., Jones, D., and Roos, D., (1990). The Machine that Changed the World. Free Press,
New York, London, Toronto, Sydney.
Yau, N., (2013). Data Points: Visualization that Means Something. Wiley, Indianapolis, IN,
Canada.
103
7 - Appendix A.
Source: Home DSMweb.org / Interview template for DSM data collection (C) 1999 MIT DSM
Research Team
fill
I
man"
E=W
111110
;
I
I 'I
I
II
II
104
(This page intentionally left blank)
105