Discussion Paper No. 84
Managing new product development process
and project leaders
for modular architecture development: Framework of two- stage NPD process
and module leaders
Tomoatsu Shibata
May, 2018

Data Science and Service Research
Discussion Paper

Center for Data Science and Service Research

Graduate School of Economic and Management
Tohoku University27-1 Kawauchi, Aobaku

Sendai 980-8576, JAPANManaging new product development process and project leaders
for modular architecture development: Framework of two- stage NPD process and module leaders
Tomoatsu Shibata
Graduate School of Economics and Management, Tohoku University
Town/City:27-1 Kawauchi, Aoba-ku, Sendai, Japan
Phone number:81+22+795+6278
E-mail: tomoatsu.shibata.c1@tohoku.ac.jp
Summary:This paper proposes a new product development (NPD) process and new project leaders suitable for a
modular architecture development. Based on theoretical considerations and an in-depth analysis of thecommon module family (CMF) architecture of Nissan Motor Company Ltd., this paper argues that a
modular architecture strategy requires both a two stage NPD process and module leaders. This differsfrom conventional overlapping processes and heavyweight (HW) project leader. This NPD process fora modular strategy comprises two stages. First, the NPD process starts by the formulation and freezingof design rules. Second, concurrent component development activity. This sequence is mandatory, witha distinct boundary between the two stages. Formulation of design rules in the first stage requires alearning process, and an organizational arrangement promoting close coordination between technicaland strategic views, enabling their integration. Also, to sustain the modular strategy, not only an HW
project leader responsible for each product, but a module leader responsible for managing the modular
concept are necessary. Otherwise, the modular strategy may collapse due to its fragility, even if started
successfully. Based on these findings, this paper proposes the framework for an effective NPD process
and project leaders in terms of product architecture.
Keywords: Modularity, Design rules, Product architecture, HW project leader, Platform leader, Module
leader1

1. Introduction
Despite increased attention to modularity over the past decade, an important area remains
relatively unexplored. It concerns a new product development (NPD) process suitable for a modular
product and project leaders required to sustain the modular strategy. In particular, the process of
formulating design rules within the NPD process has not been fully investigated.
Modular architecture with standardized interfaces among different components has shown several
benefits, including cost reductions, flexibility and reduced time to marketing. These advantages havegiven rise to the tacit assumption, that the design rule for modular architecture has been specified
beforehand. Actually, firms can only fulfill the promises of modularity if they can specify
architecture ex ante (Cabigiosu and Camuffo, 2012). The design rule, which is critically important forbuilding modular architecture, defines how a product is divided and the interface between divided
parts (Baldwin and Clark, 2000). The development of subsequent components must proceed underconditions that follow the established design rule. Despite its impact, the process of formulating adesign rule has not yet been fully investigated. This paper proposes a new NPD process suitable forthe modular strategy, and should therefore include the stage of design rule formulation.
Several automobile manufacturers, including Volkswagen (VW) of Germany and Nissan of Japan,
have adopted the principle of modularity to meet local market needs through various combinations ofmodules. The goal underlying this major trend is to achieve both customer orientation and costcompetitiveness in fast-growing emerging markets.
Formerly, automobile manufacturers developed cars with integral architecture, the opposite ofmodular architecture. As integral architecture does not require a design rule, automobile
manufacturers have not had to formulate design rules. At present, however, these manufacturers havechanged their product development strategy, from integral to modular architecture, and they havegone through the NPD process for modular product and design rule formulation. Therefore, toaddress our research questions, the automobile manufacturers have provided useful observations
enabling analysis of the NPD process, in particular of design rule formulation.
This study analyzed the process by which Nissan Motors developed a modular architecture called
the common module family (CMF) and the design rules for this process. Based on an in-depth casestudy and theoretical consideration, this study attempted to identify an NPD process suitable fordeveloping a modular product. This analysis led to our proposal of a two stage NPD process andmodule leaders, differing from the conventional overlapping NPD process and HW project leaders .
The paper proceeds as follows. Section 2 reviews existing literature and the need to develop new2

NPDs. Section 3 describes the research method. Section 4 illustrates the case of Nissan Motors,
which have successfully adopted a modular strategy. Section 5 proposes a two stage NPD process
and module leaders for developing modular products. Finally, Section 6 is the conclusion withmanagerial and theoretical implications.

2 Previous research and position of this paper
The present research lies at the intersection between NPD processes and product architecture.
Therefore, we will first review previous research on product architecture, followed by a review of
research on NPD process.

Product architecture
Product architecture has been defined as the scheme by which the function of a product is allocatedamong its physical components (Ulrich, 1994). Modular and integral architectures have been defined
as ideal types.
Previous research on product architecture since the 1990s can be categorized roughly into twogroups (Baldwin and Clark, 1997, 2000; Langlois and Robertson, 1992; Robertson and Ulrich, 1998;
Ulrich, 1995; Sanchez and Mahoney, 1996; Shibata, Yano and Kodama, 2005; Shibata, 2009;
Sanchez, 2008; Sanchez, 2013). Several of these studies compared the benefits of modular andintegral architecture, whereas other studies investigated the dynamism of product architecture froman evolutionary perspective.
A common framework analyzing the benefits of modular architecture is based on comparisons ofvarious examples of integral with modular architecture, such as changes in the relationships between
product architecture and organization. This represents a static analytical framework, with previous
research clarifying the benefits of modularity, including reductions in the costs and increases in the
speed of development (Robertson and Ulrich, 1998; Ulrich, 1995; Sanchez and Mahoney, 1996;
Shibata, 2008).
Much research in this category has emphasized the potential benefits of modular architecture(Sanchez and Mahoney, 1996; Baldwin and Clark, 1997). Modular architecture can be usedstrategically to increase product variety, improve speed to market, more radically upgrade products,
and reduce costs of design (Baldwin and Clark, 1997, 2000; Langlois and Robertson, 1992;
Robertson and Ulrich, 1998; Ulrich, 1995; Sanchez and Mahoney, 1996; Shibata, Yano and Kodama,2005). The mirroring hypothesis suggests that organizations should be designed as reflections of the3architecture of the products they develop (Sanchez and Mahoney, 1996). Product architecture canthen determine effective means of task partitioning and information exchange. Thus, productmodularity can lead to modularity of the organizations designing and producing these products(Sanchez and Mahoney, 1996).
An analysis of the development of multi-technology products, such as aircraft engine control
systems, yielded results at odds with previous research on modularity (Brusoni, Prencipe and Pavitt,2001). Rather, to cope with imbalances resulting from uneven rates of development of thetechnologies of different components and unpredictable product level interdependencies,
multi-technology firms require more knowledge than is required for manufacturing. Uneven rates oftechnological change in multi-technology products create a performance imbalance amongst
components that may require an intermediate stage of integration; e.g., loosely coupled organizations
coordinated by systems integrators (Brusoni and Prencipe, 2001). These arguments suggest theabsence of one-to-one correspondences between product architecture and organizational architecture,and that product modularity may call for highly interactive organizational arrangements.
Regarding modular and architectural innovation, architectural innovation is defined as a change inthe relationships between a product’s components, and organizations are built around stable productarchitectures. It has been postulated that the product architecture defines information processing
capabilities, communication channels, and information filters within the organization. (Henderson
and Clark, 1990). These contributions have highlighted the managerial implications of modularity inproducts and organizations.
Other research was performed to understand the logic and evolution of product architecture. The
computer industry was analyzed in detail to determine the evolutionary processes in this industry as afunction of the complex adaptive system framework paradigm (Baldwin and Clark, 2000). Several
evolutionary tracks are created in an object with modular design, without the object controlling theevolutionary tracks. This is due to the individual effects of six operators (e.g. splitting) on each
module, perhaps explaining the rapid and various evolutionary tracks within the computer industry
after emergence of the modularized IBM System/360.
Other research based on an evolutionary perspective includes discussions of a dynamic shift inarchitecture (Chesbrough and Kusunoki, 2001) and of module dynamics (Shibata, 2009). Thesestudies showed that product architecture moves gradually, from integral to modular, later returningfrom modular to integral after technical breakthroughs of the system. Thus, existing studies of
product architecture can be categorized into the above two groups.
4However, another important area remains relatively unexplored, identifying the optimal NPD
process, including design rule formulation, suitable for developing modular products. Therefore, wewill review existing literature on the NPD process and discuss the necessity of building a new NPD
process for a modular strategy.

New product development (NPD) process
Effective NPD processes are characterized by overlapping process (Takeuchi and Nonaka, 1986;
Clark and Fujimoto, 1991), in which the same tasks are completed by multiple entities while
information is shared among the various involved departments.
In overlapping, the design specifications are not fixed during early stages of development. Rather,
the final specifications are determined through close coordination among various departments once
development begins. This process has been called the rugby style of development because, like rugby,
the development process will be performed by multiple departments that share information and tasks.
Leading companies have used the overlapping process to maximize reliability and delivery. The
overlapping process requires an organization capable of managing complicated information flow
among departments. Organizationally, Japanese companies have used a heavyweight project manager
system to manage the complexity of information sharing (Clark and Fujimoto, 1991). Actually,
Japanese carmakers have implemented internal heavyweight project manager systems using different
names. For example, Toyota calls a heavyweight project manager a chief engineer. Companies inother countries have also tried to learn and implement these practices.
Overlapping, however, is not always successful, with its effectiveness depending on the industry.
For example, overlapping was reportedly unrelated to the product development process in thecomputer industry. Rather, technology integration has been found to affect performance in themainframe computer industry (Iansiti and West, 1997; Iansiti, 1998). These differences are due torates of change in the computer and automobile industries, with the former changing more rapidly
and the latter remaining more stable (Eisenhardt and Tabrizi, 1995). Overlapping is consideredineffective in the fast-changing computer industry, with speed of market changes being one factor
influencing the effectiveness of overlapping.
Aside from the speed of market change, this paper explores another factor influencing theeffectiveness of overlapping process and HW project leaders. It sheds light on the importance of
product architecture to an effective NPD process, and suggests an effective NPD process may bereliant on the product architecture, integral (non-modular) or modular architecture. This paper
5proposes a new NPD process and new project leaders suitable for modular architecture. Throughthese considerations, we aim to advance the understanding of effective NPD process from theperspective of product architecture.

New type of NPD process and project leaders for a modular strategy
In overlapping processes, design rules, including interface rules, are not fully specified or fixedduring the early stages of development. Thus, frequent interface changes are likely to be made by thevarious component development groups. Conflicts among component groups over component
interfaces are likely to become common. Management of these conflicts will require heavy weight(HW) project managers to play important roles during overlapping NPD processes. These features ofan overlapping process are not suitable for the development of modular products. An overlapping
process and HW project manager will be more effective for non-modular than modular productarchitecture. Thus, the development of modular products requires new NPD processes, including
design rule formation processes, which differ from overlapping processes.
Design rule matters for modular architecture. The design rule defines the division of a product andthe interfaces among these divisions (Baldwin and Clark, 2000). For modular architecture, the design
rule indeed matters, and formulating it requires a learning process. In determining how to divide a
product system into modules, there are, in principle, innumerable choices. Thus, it is not an easy
matter to determine the method of division, or the design rule of modularity, that will optimize theexpandability and reliability of the system as a whole. Simply dividing the system into modules isinsufficient. Many combinations must be considered when creating correspondences between
functional and structural elements and in grouping structural elements. Accordingly, the selection of amethod of division and certain combinations from among the available choices will probably lead todifferences in product functionality and performance. Furthermore, the various individually designed
subsystems must function well as an entire system after integration.
Therefore, design rules must be formulated to optimize the overall performance and reliability ofthe entire product system. Companies must determine the divisions that are needed, as well as theirinterfaces, to effectively accomplish these goals. Therefore, the process of design rule formulation isa type of learning process, and learning about product design occurs in the midst of this trial anderror process (Shibata and Yano, 2003). Thus, design rules will be established through accumulated
knowledge, experience, and expertise of a company. The process involves organizational decision
making as well as organizational learning. Only after completion of the design rule can the6concurrent developing of components commence. The task of design rule formation is therefore
completely different from that of component development. The nature of formulating design rules isdifferent from that of developing components concurrently.
Therefore, this paper proposes a two stage NPD process suitable for modular products, where thestage of formulating the design rule is clearly separated from the stage of component development. In
addition, maintaining modular architecture as the product develops with variation is a different story
from commencing modular architecture development. Even if a modular strategy has started
successfully, its continued effectiveness requires project leaders in addition to

the traditional HW

project leader responsible for each product. Just one HW project leader is insufficient for an effective
modular strategy. Therefore, this paper emphasizes a shift of importance in project management style
from HW project leaders to ML (module leaders) for modular products to maintain the modular
concept in developing product variation.

3 Research Method
3.1 Case study and data
Due to the exploratory nature of this study, a qualitative, in-depth case study methodology was
adopted, enabling the collection of comprehensive data and the generation of theoretical findings that
could not be derived satisfactorily from existing theory. The development of theoretical insights andfindings based on case studies can result in initiation of the study as close as possible to the ideal ofno theory under consideration and no hypothesis to test.
Case studies have been shown effective in assessing the relationships between causes and resultsof business phenomena and their appropriateness from multiple perspectives and interpretations(e.g., Eisenhardt, 1989; Pettgrew, 1990; Yin, 1994). Case studies can provide deep insights basedon objective qualitative information and researchers’ subjective interpretation of individual cases,
insights not provided by statistical analyses. Case studies not complementing generalities based on
statistical methods can help in constructing novel, creative theories.
The case study described in this paper focuses on research questions related to the NPD processof developing CMF in a company. It provides in-depth analysis and observations regarding how thatcompany developed a modular product. This case study of Nissan is based on the authors’ interviews
with a number of company executives, including one board member and five officers, as well as oninternal information and data (including corporate information in the public domain).
7

Five in-depth, semi-structured interviews, each lasting about two hours, were conducted during
2012 and 2013. Interview data were complemented by follow-up communications via telephone andemail. The case of Nissan CMF was constructed using data from interviews, published productliterature, and Nissan’s technical documents. For validation, a draft of the case was circulated to theindividuals interviewed, who made corrections where appropriate.

3.2 Framework of case analysis
This paper focuses on Nissan CMF because it achieved modularity between two companies withdifferent histories and traditions, Renault and Nissan. It is difficult to promote modularity within one
company, so modularity between different companies will be far more difficult and complex. CMF isan extreme case in this sense, providing the essence of the mechanism behind superficial phenomena.
The purpose of this paper is to identify and develop new NPD processes for the development ofmodular products. The framework of analyzing the NPD process for the CMF therefore has two
viewpoints. The first is the stage of formulating the design rule, when compared with the stage ofcomponent development. That is, should there be clear boundaries between the design rule
formulation and the component development processes? The second viewpoint is the organizational
viewpoint regarding the process of formulating a design rule. That is, how should the process be
divided among related departments and who should lead the process?
Based on a case analysis of CMF and theoretical consideration, we will build an NPD process
suitable for the development of modular architecture. Modular architecture here refers to a closed
module, wherein the design rule is proprietary within a company, as opposed to open modules likepersonal computers. However, the two are the same in that both require clear design rules.

4 Case study: NPD Process for the Nissan CMF
On February 27, 2012, Carlos Ghosn, the President and Chairman of Nissan, introduced the 4+1
CMF to the media as a fundamental change to the vehicle design concept.
“4+1” means four structure modules (engine compartment, front underbody, cockpit, and rearunderbody) and one electrical module (electrical/electronics architecture), which are called big
modules. The interface rules between pairs of big modules are formulated from both a physicalstandpoint (including position, dimension and form, collision safety, and the input/output of sound,vibration, and heat, among others) and an electrical standpoint. Each of these big modules has a8number of design variations for a mid-class vehicle, specifically two types of engine compartments,
three types of front underbodies, three types of cockpits, and three types of rear underbodies. Thus,
there are theoretically 54 combinations of these four big modules (2 × 3 × 3 × 3 = 54), resulting in 54
different vehicles.

Fig. 1. Conceptual diagram ofcommon module family (CMF)

Source: Nissan global site

In contrast, the electrical/electronic architecture uses one type of hardware and one type ofsoftware for all variable parts.
The CMF was designed to generate vehicles with different designs and functionality, while
promoting standardization, and to create an optimum balance between product variation and volume
efficiency. If component-sharing creates significant cost savings, funds can be invested inenvironmental and safety measures, which will increase the competitiveness of this product in the
future. Moreover, the application of new technology can enhance developmental efficiency of many
types of vehicles, a process that has to date been applied only to luxury cars.
Previously, automobile manufacturers standardized components used on the same platform(chassis). However, this approach has limitations. In developing the CMF, Nissan aimed tostandardize components for different platforms (cross-platform), effectively eliminating the platform
concept. In designing the CMF, components were classified not by platform but by the element inwhich the component could vary. For example, engineers could first consider whether weight or otherelements should vary. In the former case, they would consider a basic design, in which components
could vary by weight. As a result of the CMF, the compatibility between Nissan and Renault
9drastically increased, from 6% to 53%, based on the prices of the components, reducing component
costs by 30%. This was considered more remarkable because it did not impair product variation whencompared with conventional methods.
The project of developing CMF officially began in September 2009, with the first year devoted toformulating the design rule. Once the design rule was established, the project shifted to concrete
product design at the end of 2010. The first CMF-based mass production started in autumn 2013 withthe launch of the new X-TRAIL. A total of 1.6 million vehicles, consisting of two types of Nissanvehicles, including the X-TRAIL, and 10 Renault models, were introduced to the market sequentially.
The designs of all of these new models were based on different combinations of the five big modulesof the CMF. In the future, Nissan will apply the CMF to all vehicles, except those that require a
specific manufacturing process. The next Section describes the CMF developmental process andorganizational arrangement.

4.1 Establishing an interface between big modules
Because the goal of the CMF is the development of cars using combinations of 4+1 big modules,
one of the important design rules concerns the compatibility of the physical and electrical interfaces
between pairs of modules, a process developed sequentially from September 2009 to the end of 2010.
The physical interface includes the widths of the lower dashboard and floor, the points of installationof the air conditioning unit and the front seat rail, and the penetration position of the lower dashboard,among others. Similarly, the electrical/electronic interface includes assigning functions to thecontrollers and assigning controllers to a network, which triggers functionality, and the methods ofsupplying electricity to the body control module (BCM) and other components. These two types ofinterface rules were determined sequentially between each pair of big modules.
One of the most important factors in this process is accumulated knowledge and experience of“simulation technology”, with the most difficult being the collision experiment. However, as Nissan
has accumulated experimental data over many years, there is little difference between collisionexperiments using actual vehicles and the results of computer simulation, making it possible to finetune designs once the big modules are combined. This high correlation between real and simulated
data enabled collisions to be simulated, a process previously difficult to perform. This cutting-edge
simulation technology contributed significantly to improvements in the design capacity of Nissan.
According to Nissan, without the simulation technology, it would not have been possible to formulate
a design rule for CMF.
10

The procedure used to formulate interface rules between big modules began by setting a target
performance value for each vehicle. This was followed by changes in the boundary and synthesis
conditions of the interfaces between the big modules. Simulations were used to determine theconditions required to reduce the interference ranges between modules as much as possible toachieve the vehicle’s target performance. Adjustments were made based on feedback and thesimulation was repeated. These cycles were repeated until target performance was reached.
According to Nissan, simply integrating the big modules will lead to completion of about 80% ofeach vehicle.
4.2 Strategic issues of design rule
While the interfaces between big modules were being developed, solutions to the strategic issuesof design rule within the big modules were promoted. The most difficult issue was determining
where and how common parts and variable parts should be separated within a big module, a problem
that must be resolved by formulating the design rules for each big module. This is more than atechnical issue, as it requires strategic considerations of various conditions.
The first strategic issue arises from differences in market requirements; for example, requirements
may differ in Asia and North America. Thus, there is a risk that sharing components sacrifices somemarket requirements. However, without component-sharing, it would not have been possible toefficiently manufacture an appropriate number of vehicles. This requires determination andpromotion of the most appropriate level of component-sharing. Similarly, component sharing must
avoid damaging the brand image of each model vehicle, an issue that arises even forcomponent-sharing within a company.
The second strategic issue arises from the differences in technical policies between the two
manufacturers. Nissan calls its basic policy on the technology resulting from its accumulated historicexperiences the Technical Policy. As both companies have different histories, it became difficult tojudge which parts should be common to both and which should vary. In the case of CMF, thedifference in technical policies became critical for promoting component-sharing between Nissan andRenault.
For example, the design method aimed to avoid accidents and to ensure strength and the absorptionof collision energy depended largely on each company’s technical policy. Similarly, each company
had different policies for the placement of the AC compressor control. At Nissan, this unit wascontrolled by an electronic control unit, whereas, at Renault, this unit was controlled by another unit.
This difference depends largely on policy rather than technology. Companies with different histories
11will develop different policies, which are reflected in differences in design activity and the products
themselves.1
Thus, to promote component-sharing between Nissan and Renault, the differences in technicalpolicies had to be overcome, in addition to resolving issues caused by differences in market
requirements. These are beyond the technical perspective. Rather, they concern strategic perspectives
related to prerequisites in starting design activity. Nissan termed an issue obstructing
component-sharing a Road Block (RB). The CMF project formulated a basic policy that actual
component developments could not begin until all RBs were completely solved. RB resolution was
set as a top priority in CMF project. Figure 4 shows that the 859 RBs at the end of 2009 decreased
rapidly within one year.

4.3 Organization and Process to Solve Road Blocks
Organizationally, the design department alone could not resolve RBs, because the technicalcapacity of that department was not sufficient for resolving strategic issues. Nissan developed a neworganizational system, in which both technical and strategic (market requirement and technicalpolicy) perspectives were incorporated to resolve RBs. Figure 2 shows the essence of thisorganizational system, which became a strong driving force promoting RB resolution andformulating design rules. The most important feature of the system was the introduction of both thetechnical capacity of the upstream strategic functional team (USFT) and the strategic capacity of the
Joint Steering Committee (JSC). As the organizational system to resolve these RBs, the close
cooperation and adjustment between the JSC and the USFT enhanced the role of the component
design department.
The JSC was tasked with resolving RBs at the General Management level of both Nissan andRenault, and appointed the appropriate team members to deal with the issue at hand. Various types oftechnology, knowledge, and know-how were required to solve the more than 800 RBs. Therefore, thecompanies established a flexible organization, enabling suitable members to come together according
to the contents of an RB.

12

Fig. 2. Organizational system for formulating
design rules
Alliance director
dispatch

CCT(Crosscompany
team)
Executive
level

Design rule formulation
Strategic view

Technical view

JSC＃１
component
approval

JSC＃２
architecture
JSC＃３
electronics

USFT#1
USFT#2
Information
sharing

Adjustment

USFT#75
USFT#76

report JSC＃４

marketProblem
resolution

registration
Joint steering committee
Component department

The USFT is a component design department that develops products and to which work was
assigned relative to each component system, such as seats and steering. The total number ofcomponents per car was approximately 30,000, divided into 76 component systems, with one USFT
assigned to each system. As each USFT has approximately 20 members, about 1,500 persons, allmembers of the USFTs, were involved in component design.
In addition, the official reporting channel shown in Figure 2 contributed to resolving RBs. The JSC,
in coordination with the USFT, provided monthly progress reports on RB resolution to the crosscompany team (CCT), a management team composed of executives, including Vice Presidents, which
promoted RB solutions. Simultaneously, the JSC consulted with the USFTs about unresolved issues
and other difficult matters, seeking direction in some cases.
The process of formulating a design rule within each big module started with collecting as many
issues as possible obstructing component-sharing from the requisite USFTs. Each USFT had strong
incentives to promote component-sharing through the modular concept of CMF.
The first step in promoting component-sharing was identification of the obstructing factor. All
members of the USFTs were asked about impediments to standardizing the components and why
sharing was difficult. By November 2009, this process had identified 859 issues obstructing
component-sharing. These issues were registered in a database of RBs to resolve. The 859 RBs werebroadly divided into four groups of problems; for example, those related to mechanical architecture
or market requirements, and assigned to four JSCs. Issues related to components were assigned to13

JSC #1, issues related to mechanical architecture to JSC #2, issues related to electrical/electronics
architecture to JSC #3, and issues related to market and product requirements to JSC #4. Each JSC
included six General Managers, three each from Nissan and Renault, and administered by the
Alliance Directors. These JSCs were tasked with solving the RBs reported by the USFTs. As RBs
could not be resolved only by USFT employees with technical capacities, the JSC tried to apply
strategic perspective, such as market and technical policy, to RB resolution. If necessary, a JSC asked
other department to collect new, experimental data and conduct additional market research.
Effectively solving RBs required close cooperation between the JSC and USFT. The component
layout issue provides an appropriate example. The body control module (BCM), which controls
power windows, had been installed in different places in different model vehicles. This resulted indiverse types of wire harnesses, the cable used to connect the BCM with other devices in the car. This
problem could be solved by aligning the technical policy about the layout of BCM, which would
standardize the wire harness. However, the USFT responsible for developing the wire harness could
not solve the issue of the BCM layout. Rather, the JSC, which has strategic perspective, led the work
to standardize the BCM layout, making it possible for the USFT to develop a standardized wire
harness based on the standardized BCM layout. Decisions about standardization of the BCM layout
and wire harness required frequent information sharing and adjustment between the JSC and USFT.
Therefore, Nissan developed an organizational system that enabled close cooperation and adjustment
between JSC and USFT (Figure 2).

Fig. 3. Process of resolving road blocks
1200

1000

800

600

400

200

0
Nov

2009

Dec

Jan

Feb

Mar

Apr

number of unresolved road blocks

May

June

Oct

Dec

total number of road blocks

source： Nissan

14

Figure 3 shows that the 859 initially identified RBs were resolved within one year. In this way,
Nissan made every effort to resolve all RBs before starting actual component development.2

4.4 Project leaders for maintaining CMF modular concept to all of market segment:
CVE (Chief vehicle engineer), APFL (Alliance Platform leader) and ABML (Alliance big module
leader)Fig.4 Applying CMF architecture to all of market
segment in Nissan
Ｃ／Ｄ segment（ＣＭＦ Ｃ／Ｄ）

price
Ｂ segment（ＣＭＦ Ｂ）
Ａ segment（ＣＭＦ Ａ）

Ｘ－ＴＲＡＩＬ(2013）
Qashqai (2013)

Kicks(2016）
Micra(2016)

redi-GO(2015）

Car width
4

After solving all RBs and formulating design rules in the first stage, Nissan started producing
actual components and integrating them into each vehicle in the second stage. Producing a CMF
vehicle requires a person to coordinate the combinations of these big modules. Combinations ofmultiple big modules must follow interface rules to ensure the integrity of each car for the customer.
The person is called Chief Vehicle Engineer (CVE) in Nissan, corresponding to an HW project
leader.
CVEs are responsible for the technical performance of each completed vehicle, and therefore
focus on each vehicle type to maximize its value while differentiating it from other types. It is nowonder that a CVE might have a natural tendency to prefer customized components instead ofstandardized components to generate maximum performance and maximum value in their particularvehicle. In this way, the desire of a CVE to develop as much value in his car as possible may tend to15

sacrifice component sharing with different types of cars, which must ultimately risk destroying the
CMF modular concept.
The first CMF-based car commercialization started in 2013 with X-TRAIL targeting C/D market
segment. Until 2016, Nissan applied the CMF concept to market segment B and A

beyond segment

C/D, and introduced six types of vehicles sequentially. Figure 4 shows in detail that two vehicle types
in segment C/D, two in segment B, and one in segment A have been introduced to the market.
In 2015, two years after introducing the first CMF- based mass production car, Nissan established
new posts of two project leaders described in Figure 5. Because Nissan noticed the necessity thatkeeping the CMF concept requires not only a CVE but also other project leaders responsible formanaging design rules and component sharing beyond each specific vehicle in applying the CMF
concept to other market segments than C/D. As shown in Figure 5, both APFL (Alliance platform
leader) and ABML (Alliance big module leader) were additional project leaders to CVE
corresponding to HW project leaders. To maintain the CMF modular concept, modularity needs to be
managed in two dimensions, namely dimension of market segment and dimension of big module.
In 2015, Nissan created new positions tasked with the responsibility of ensuring maximum
component sharing as possible in each market segment. Nissan called this position Alliance platform
leader (APFL). There are three classes of CMF corresponding to different market segments CMF A,
CMF B, and CMF C/D, respectively. Each APFL is responsible for managing modularity in theirmarket segment. For instance, APFL for segment B is responsible for enforcing design rules andmaximizing component sharing for not only Micra but Kicks in Figure 4.
Similarly, in 2015 while applying the CMF concept, Nissan noticed a growing possibility thatdesign rules and component sharing within each big module might be at risk of sacrifice with strives
for product variation. So, Nissan introduced the role of ABML (Alliance big module leader), whose
responsibility was to ensure the design rules were followed and maximize component sharing withineach big module. There are four big modules in CMF architecture, namely engine compartment, FR
under body, Cockpit, and RR under body. Therefore, Nissan established four ABML each responsible
for one big module.

16Fig.5 Project leaders for keeping CMF
modular concept
APFL responsible for component sharing inthis segment

C/D segment

FR
under
Body

EngineCockpit

RR underbody

CVE responsible for maximizing value of specific vehicle

B segemnt

Engine

FR
under
body

5

Cockpit

RR
under
body

ABML responsible for component
sharing in big module

5 Discussion
Although there are limits to what can be inferred from analysis of this single case, the wealth ofdetail available in this case should provide empirical findings relevant to the NPD process ofdeveloping modular architecture. Based on in-depth case analysis, we wish to discuss threecontributions mentioned below.

5.1 Two stage NPD process for modular architecture development
This case revealed that Nissan first formulated design rules by the end of 2010 before beginningconcrete product development. In fact, their CMF first established design rules, such as interfaces
between big modules, and considered appropriate boundaries between common and variable parts. At
the end of 2010, when the design rules were formulated through resolving RBs, Nissan started
designing actual components. This NPD process was a completely new approach for Nissan, when it
adopted this CMF project. Through accumulated experience and knowledge of past projects, Nissan
had learned that conventional and overlapping NPD processes were not appropriate for developing
modular products.
Analysis of this CMF case and theoretical considerations indicate that the new NPD process was
suitable for developing modular products. This process consists of two different tasks, design rule
formulation, followed by concurrent development of components according to the established design17rule (Figure 5). This sequence should be strictly observed during the two stage NPD process.
The design rules can have a critical effect on the success or failure of modularity, sincesubsequent concrete design activities are constrained by the design rules. Successful modularity
therefore requires that concrete product development begins only after the design rules are set.
Changing the formulated design rules during the component development process will result in an
open-ended development project and the consumption of management resources. This pattern offailure has been frequently observed in unsuccessful modularity projects (Sanchez, 2013). Therefore,
a two stage NPD process should draw a clear line between design rule formulation and component
development.
During the second stage, the component development process, each component team will be able
to focus its activities on individual components, without paying attention to other components. Thisrequires the design rule to be fully specified and fixed, providing a stable environment that it enables
all subsystems and components to be developed concurrently (Sanchez, 2015). Proposing this new
NPD process for a modular strategy is this paper`s first contribution to existing research on
modularity.

Fig. 6. Two stage new product development process(NPD) for modular architectureFirst stage

Integrative
process
acrossdifferent
viewpoints

Process

Second stage

Design rule

Concurrent
developmentof components

Architecture

Process

2018/5/5

6

5.2 Design rule formulation as a learning process
In the two stage NPD process, the first stage consists of decision making about the design rules.
18Based on the CMF case, we will determine the nature of design rule formulation, followed by theorganizational process of developing a design rule.
As this case showed, the CMF project had to solve two kinds of issues, those requiring a strategic
perspective for RB resolution, such as adaptation to different market requirements and different
technical policies, and those requiring organizational technical capacities, such as simulation
technology. Even if strategic perspective issues can be solved, excellent component-sharing will
require the technical capacity to perform concrete product development. In contrast, even at a highlevel of technical capacity, excellent component-sharing comes only through the resolution of RBs
from a strategic perspective.
Theoretically, this paper suggests that design rule formulation needs more than a technicalperspective. Excessive component-sharing sacrifices adaptation to different market requirements,
whereas insufficient component-sharing does not produce volume efficiency. Therefore, design rules
will have to balance market requirements and volume efficiency. This task cannot be resolved only
from a technical perspective; rather, it requires a strategic perspective. In the case of CMF, there were
two types of strategic issues, adaptation to different markets and adaptation to different technicalpolicies without sacrificing volume efficiency. Design rules will therefore be influenced by two
factors, the resolution of both strategic and technical issues.
Conventionally, design rule formulation was regarded as a purely technical issue, resulting indevelopment tools such as Design Structure Matrix (DSM), based on a technological viewpoint(Baldwin and Clark, 2000). DSM is a design method to determine boundaries between subsystems,
such as components and tasks, by focusing on the strength of interdependent relationships. DSM tries
to minimize the complexity regarding the technical interdependence between subsystems, but does
not consider needs of different markets. Therefore, DSM cannot provide the strategic perspective
necessary for design rule formulation, requiring complementation by organizational arrangement.
Understanding this nature of design rules, Nissan established a new organizational system todevelop an effective design rule. Indeed, the CMF project has successfully increased the component
sharing rate because of the design rule. Within the CMF project, USFTs do not have authority to
manage strategic issues alone, because engineers were unable to formulate design rules due tostrategic factors beyond their control. To resolve this issue, JSCs, with the power to resolve such
issues, were established and staffed with General Managers from both Nissan and Renault by the
Alliance Directors. The Alliance Directors are the highest decision-making bodies across bothcompanies. The JSCs led the process of RB resolution, improving preconditions for19

component-sharing. This organizational system was a completely new approach for Nissan, first
adopted for the CMF project.
The development of design rules requires close coordination between departments with a technicalperspective and other departments with a strategic perspective during the first stage of the NPD
process. Through close coordination and information sharing, technical departments learn strategic
perspectives while strategic departments learn technical perspectives. The design rule formulation
process is therefore a type of learning process to find solutions to problems through close
coordination and adjustments between two different perspectives. Thus, design rule formulation
process can be conceptualized as a learning and decision-making process.
Furthermore, when formulating design rules, the involvement of engineers alone is not enough.
Executive-level senior managers should be actively involved during the early stages of development.
Senior members must lead the design rule formulation to resolve strategic issues. Moreover, therequirement for their active involvement for a longer period, beginning at earlier stages, constitutes asignificant change from conventional development processes, where their involvement was limited toearly planning stages.
Clearing both the nature and the process of design rule formulation are the paper`s second
contributions to existing research on modularity.

5.3 Emerging role of new project leaders due to fragility of modular strategy
Modular architecture development requires the addition of project leaders different from theconventional project leader. In a conventional overlapping NPD process, frequent interface changes
are likely to be made among the various component development groups. Conflicts over component
interfaces are likely to become common. As existing literature shows, management of these conflicts
requires heavyweight (HW) project leaders. An HW project leader is like a president residing over anassigned car, which means they are almighty in decision making of every aspect of that car. In thecase of Nissan, the CVE play the roles of HW project leaders.
However, the features of HW project leaders do not suit the modular architecture concept, because
they tend to focus on improving the quality of their assigned car as much as possible, and may prefercustomized above standardized shared components. This may ultimately lead to collapse of themodular concept, accordingly the modular strategy is fragile. To overcome this fragility, a modular
strategy requires a person with responsibility to manage interfaces, enforce the design rules, andmaximize component sharing. In the present paper, the title of this person is called the module leader
20

(ML).
Actually, Nissan CMF has established new positions to manage the modular concept of CMF whereinterface rules and component sharing need to be managed through two dimensions, market segment
dimension such as Segment B and big module dimension such as engine compartment big module.
The manager of component sharing along with segment dimension is the APFL in CMF. In contrast,
the manager of big module dimension is the ABML. The roles of the APFL and the ABML are akinto managing the interface rules and maximizing component sharing in each dimension. In thismeaning, both may be regarded as module leaders. Proposing such new project leaders required formodular strategy is this paper’s third contribution.
The difficulty facing new project leaders is that conflict will tend to occur between an HW project
leader and a Module leader, because their roles and purpose differ. Who should have the most power?
At least, a Module leader needs the same power as an HW project leader. Otherwise, the amount ofcomponent sharing might decrease and interface rules might change, resulting in collapse of themodular concept. The method of solving this power balance differs among automakers. For instance,
German VW required HW leaders to sign a pledge to strictly adhere to the design rules. In this sense,
module leaders are more powerful than HW leaders in VW (Nikkei Automotive 2016.1). Also,
Nissan CMF gave the same power to APFL and ABML as HW project managers. Nissan resolve
conflicts and make decisions, based on consensus building through dialogue and discussion among
the three project leaders.

6 Conclusions and implications
In this section, we briefly summarized what has been found here and consider what kind offramework can be derived from that discussion. Then we conclude with its implication on
management strategy.
Theoretical consideration and in-depth case analysis of CMF have shown that a modular strategy
requires a two-stage NPD process and module leaders that differ from a conventional overlapping
process and HW project leaders. The first stage consists of formulating design rules and fixing them.
The second stage consists of concurrent development of components, beginning only after the design
rules have been formulated. This sequence must be strictly observed, with clear boundaries between
these two stages. Because, the design rule formulation stage requires an integrative organizational
process across strategic and technical perspectives, which is completely different from the nature ofcomponent development in the second stage.

Also, not only HW project leaders but module leaders
21

are necessary to maintain the modular strategy.

Based on this knowledge and findings as a foundation, we can build a framework of effective NPD
process in terms of product architecture, that is, which kind of NPD process is effective depends
upon its product architecture. Existing literature identified speed of market change as one possible
factor influencing the effectiveness of overlapping process and HW project leaders. Overlapping andHW project leaders can be considered effective in stable industries such as the automobile industry,and not effective in fast-changing industries such as the computer industry (Eisenhardt and Tabrizi,
1995). In addition to the rate of market change, this paper proposes another factor influencing
effectiveness of overlapping and HW project leaders, that is, product architecture. From thisviewpoint, we argue that an overlapping NPD process must be effective for integral (non-modular)architecture, not for modular architecture. Developing modular architecture requires a different typeof NPD process and project leaders from overlapping process and HW project leaders. This paper
suggests a two-stage NPD process and module leaders as a new type of NPD process effective formodular architecture. Thus, as Table 1 shows, we propose a framework for considering an NPD
process in terms of product architecture, which will lead to advancing our understanding of effective
NPD process.

Table 1 Product architecture based framework of NPD
process and project leader
Product architecture

NPD process

Project leader

Integral (non modular) Overlapping process
architecture

HW project leader

Modular architecture

HW project leader
Module leader

Two-stage processwith clear boundaries
between each stage

7

Finally, we would like to touch upon the managerial implication of this research. Based on
22

discussion and findings so far in this paper, the change of product architecture to a modular productalso requires changes in the NPD process. Nevertheless, many modular projects continue to utilize
conventional, overlapping NPD processes. This continuation of conventional NPD processes can leadto failure of modular projects, because design rules may be changed during the component
development process.
Therefore, the success of product modularity requires engineers to observe a new rule, that, once
design rules have been established, subsequent changes are not permitted. Some engineers may
strongly resist this rule, because they are accustomed to conventional NPD processes. In
conventional processes, problems with interface rules during actual product design are resolved bytracing back through the previous processes. The conventional process adopts less restrictive rules,
with design activities beginning during early stages of development and any problems related tointerface rules resolved through later collective adjustment. Engineers are accustomed to such a
conventional development process, where design specifications are determined during overlappingfrom earlier stages.
Managers must therefore convince engineers accustomed to the conventional process and resistant
to change to adopt the new NPD process. The active involvement of senior managers becomes
important, as they must explain to front line engineers the need to adopt a modular strategy and tochange away from conventional NPD processes. Actually, in the case of CMF, the chief technicalofficer (CTO) played an important role in persuading some engineers who insisted on conventional
NPD. To persuade engineers, senior managers need deep and precise knowledge on modular strategy.
This paper has tried to clarify the NPD process and role of new project leaders for modularity, inparticular the process of development of a design rule. This research is an unexplored area borderingresearch on product modularity and new product development. Further research is expected in the
future, as this paper was based on single case study, that of the Nissan CMF.

7 References
Baldwin , Carlisss Y, and Kim B. Clark (1997). Managing in the age of modularity. Harvard Business Review,
Vol.75, No.5.
Baldwin , Carlisss Y, and Kim B. Clark (2000). Design Rules: The Power of Modularity, Vol.1, Cambridge,
MA: MIT Press.
Brusoni, S. and Prencipe, A. (2011). Patterns of modularization: the dynamics of product architecture incomplex systems. European Management Review, 8, 67–80.
23Brusoni, Stefano, Andrea Prencipe and Keith Pavitt (2001). Knowledge specialization, organizational coupling,
and the boundaries of the firm: Why do firms know more than they make? Administrative Science Quarterly,Vol. 46, December, 597-621.
Brusoni, Stefano, Andrea Prencipe (2006). Making design rules: a multidomain perspective. Organization
Science, Vol. 17, 179-189.
Brusoni, Stefano and Andrea Prencipe (2001). Unpacking the black box of modularity: technologies, products
and organizations. Industrial and Corporate Change, Vol. 10, No. 1, 179-205.
Cabigiosu, A. and Camuffo, A. (2012). Beyond the ‘mirroring’ hypothesis: product modularity andinterorganizational relations in the air conditioning industry. Organization Science, 23, 686–703.
Chesbrough, Henry W. and Ken Kusunoki (2001). The Modularity Trap: Innovation, Technological Phase
Shifts and the Resulting Limits of Virtual Organization, I. Nonaka and D. Teece, Eds., Managing Industrial
Knowledge, London: Sage Press.
Christensen, Clayton and Raynor (2003). The Innovator's Solution, Harvard Business School Press, Boston,
Massachusetts.
Clark, K. B., and Fujimoto, T. (1991). Product development performance: Strategy, organization, andmanagement in the world auto industry. Boston, MA: Harvard Business School Press.
Eisenhardt, K. (1989). Building theories from case study research. Academy of Management Review, 14,532-50.
Eisenhardt, K. M., and Tabrizi, B. N. (1995). Accelerating adaptive process: Product innovation in the global
computer industry. Administrative Science Quarterly, 40, 84-110.
Fine, Charles, (1998). ClockSpeed: Winning Industry Control in the Age of Temporary advantage, Reading,
Massachusetts: Perseus Books.
Glaser, B.G. and Strauss, A.L. (1967). The Discovery of Grounded Theory: Strategies for Qualitative Research,
Aldine Pub. Co., Chicago.
Henderson, R and K. Clark (1990). Architectural innovation: The reconfiguration of existing producttechnologies and the failure of established firms. Administrative Science Quarterly, March, 9-30.
Hoetker, G. (2006). Do modular products lead to modular organizations? Strategic Management Journal, 27,
501–518.
Iansiti, M. (1998). Technology integration. Boston, MA: Harvard Business School Press.
Iansiti, Marco and Jonathan West (1997). Technology integration : Turning great research into great products.
Harvard Business Review, May-June.
Ingvarsson Munthe, C., Uppvall, L., Engwall, M., and Dahlén, L. (2014). Dealing with the devil of deviation:24

managing uncertainty during product development execution. R&D Management, 44, 203–216.
MacCormack, A., Baldwin, C., and Rusnak, J. (2012). Exploring the duality between product andorganizational architectures: a test of the ‘mirroring’ hypothesis. Research Policy, 41, 1309–1324.
Magnusson, T. and Lakemond, N. (2015). Evolving schemes of interpretation: investigating the dual role ofarchitectures in new product development. R&D Management. doi: 10.1111/radm.12142.
Nightingale, P. (2000). The product–process–organization relationship in complex development projects.
Research Policy, 29, 913–930.
Park, Jin-Kyu, and Young K.Ro (2013). Product architectures and sourcing decisions. Journal of Management
Vol.39 No.3,814-845.
Richard N. Langlois and Paul L. Robertson (1992). Networks and innovation in a modular system: Lessons
from the microcomputer and stereo component industry. Research Policy, 21, 297-313.
Robertson, David and Ulrich, Karl (1998). Planning for Product Platform. Sloan Management Review, Summer.
Sanchez, R. and J. Mahoney (1996). Modularity, flexibility, and knowledge management in product andorganization design. Strategic management journal, Vol. 17 (Winter special Issue), 63-76.
Sanchez (2000). Modular architecture, knowledge assets and organizational learning. Int.J.Techonology
Management,Vol.19,No.6, 610-628.
Sanchez (2008). Modularity in the mediation of market and technology change. Int.J.Techonology
Management,Vol.42,No.4, 331-364.
Sanchez (2013). Building real modularity in automotive design, development, production and after service.
Int.J.Automotive Technology and Management,Vol.13,No.3.
Salvador,

Fabrizio and Veronica Villena (2013). Supplier integration and NPD outcomes. Journal of Supply

Chain Management,Vol.49 No.1,87-113.
Shibata, Tomoatsu and Masaharu Yano (2003) Building the concept of learning by decomposing: A case ofnumerical control architecture. International Journal of Innovation management, Vol.7, No.3, 371-393.
Shibata, Tomoatsu, Masaharu Yano, Fumio Kodama (2005). Empirical analysis of evolution of productarchitecture. Research Policy, 34, 13-31.
Shibata, Tomoatsu (2009). Product innovation through module dynamics. Journal of Engineering andTechnology Management, 26, 46-56.
Siggelkow, N. (2007). Persuasion with case studies. Academy of Management Journal, 50, 20-24.
Simon, HA (1981). The Science of the Artificial (2nd Edition), Cambridge, Mass; MIT Press.
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review,(1986,January-February), 137-146.
25

Ulrich, Karl (1995). The role of product architecture in the manufacturing firm.

Research Policy, 24, 419-440.

Yin, R. (1994). Case Study Research: Design and Methods, second edition. Sage Publications Inc.

1

Another example is a different way of thinking about the layout, such as the arrangement of the engine

room, seats, persons, and others. This is determined at the first stage of the vehicle production plan byconsidering various requirements, such as center of gravity, dynamic performance, under-floor arrangement,
styling, and performance. This layout is often determined not only from a purely technical viewpoint but from acompany’s accumulated knowledge and experience.
2

According to Nissan’s estimates, if the component sharing rate is >75%, product diversity is sacrificed, as thevehicles will be too close in design. However, sufficient volume efficiency for common use requires acomponent sharing rate of 50%. Therefore, it is important to make judgments in design that balance the rate ofshared components, differentiation, and investment within a component-sharing rate of 50% ~ 75%.

26