ARTICLE IN PRESS

1478-4092/$ - se

doi:10.1016/j.pu

�Tel.: +46 36

E-mail addr

Journal of Purchasing & Supply Management 12 (2006) 246–257

www.elsevier.com/locate/pursup

Bring your suppliers into your projects—Managing the design of workpackages in product development

Mike Danilovic�

Jonkoping International Business School, Jonkoping University, P.O. Box 1026, SE-551 11 Jonkoping, Sweden

Received 27 September 2006; received in revised form 27 September 2006; accepted 10 October 2006

Abstract

Early supplier involvement and integration is important in product development on strategic as well as on operational, project and

team levels. Saab Aerospace intended to achieve early supplier involvement and high level of integration on all levels in the redesign of

the aircraft JAS 39 Gripen. The research underlying this article shows that the intended strategy was only achieved on the strategic level

and not on the operational project and team levels. One major reason for this was that the design of the work breakdown structure

(WBS) and work packages (WP) in the product development followed the functional and departmental logic within each company

resulting in incompatible structures and preventing communication and information exchange. This article intends to explore how

prevailing functionally designed WBS and WP structures created barriers and to demonstrate how supplier integration can be improved

by designing collaborative WBS and integrated WP. The Dependence Structure Matrix (DSM) is introduced in order to analyze,

visualize and manage interdependencies and information exchange between Saab Aerospace and its supplier on different levels of the

WBS and in different phases of the development process, following the logic of interdependencies and information flow, in order to

support a strategy focusing on integration of suppliers on the project and team level.

r 2006 Elsevier Ltd. All rights reserved.

Keywords: Supplier integration; Collaborative product development; Integrated product development; Dependence structure matrix; DSM; Concurrent

engineering

1. Introduction

One major reason for the success of Japanese companiesin general is their competence in collaborating withsuppliers. The Japanese lean production system uses asmall number of suppliers (Womack et al., 1990; Womackand Jones, 1994), who have responsibility for largermodules, are involved in the product development workmore intensively, at an earlier stage and continues throughthe product life-cycle. The Japanese way of working withsuppliers requires a high level of integration between thesupplier and the systems integrator (Lamming, 1993).Some empirical evidence suggests that Japanese suppliersperform four times more engineering work for a specificproject than US suppliers, while Europeans are somewherein between (Clark and Fujimoto, 1991). For this reason,

e front matter r 2006 Elsevier Ltd. All rights reserved.

rsup.2006.10.009

157588; fax: +46708 157588.

ess: Mike.Danilovic@jibs.hj.se.

the potential benefits of strategic alliances with suppliershave received considerable attention (Bonaccorsi andLipparini, 1994; Fruin, 1992; Lamming, 1989, 1987, Lyonset al., 1990; Quinn, 1992). The incorporation of suppliersinto a firm’s development process is considered a major keyto a shorter development cycle and better products (Clarkand Fujimoto, 1991; Backhouse and Brooks, 1996).In the aerospace industry many aircraft corporations

manufacture only 20–40% of the components and systemsin an aircraft themselves; suppliers are responsible for therest. In the Swedish commercial aircrafts Saab 340, Saab2000, and military aircraft JAS39 Gripen, approximately80% of the total manufacturing costs are related topurchasing goods from suppliers (Borjesson et al., 1996;Danilovic, 1997, 1999). Research by Weiss et al. (1996)indicates that the situation in the aerospace industry issimilar to that in many other industries, requiring ahigh degree of supplier involvement in the developmentprocess based on long-term relations and early supplier

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 247

involvement in design and development teams, joint riskidentification and risk sharing, as well as joint targetcosting. Some results indicate progress in terms of:

�

Locating design-build teams at the customer’s sitereduced engineering changes by 50% and cycle time by25%. � An enhanced cross-functional character of the work-

force led to a decrease in the number of job descriptionsfor engineers from 103 to 30.

� Integrated product teams, products, and process re-

sulted in significant improvements in quality, cycle time,and change orders. The post release engineering chargerate decreased by 96%.

� 50% less labour has been used to procure four times the

number of parts, while maintaining high quality (Weisset al., 1996).

During the eighties, Boeing developed a wide-bodied jetaircraft, the Boeing 777, based on ideas of concurrentengineering, establishing 238 cross-functional teams towork on the development program. The suppliers wereinvolved in the concurrent process. Boeing was thetechnical systems integrator and introduced concurrentengineering among its suppliers by applying pressure to thesupply chain. However, researchers indicate that in practicethis close systems integrator–supplier collaboration is lessevident than what could be expected. Klein and Susman(1995) claim that

[s]ince a large percentage of aircraft component partsare purchased, supplier involvement in the productdevelopment process is critical. But only 18 of the 63teams (23%) include suppliers, either full- or part-time(Klein and Susman, 1995, p. 17).

The finding from Klein and Susman (1995, p. 5) showthat in the US aircraft industry, integrated product teamsare used mostly in the engineering phase of the productdevelopment (58%), followed by demonstration andvalidation (13%), and pilot production (7%). This maybe due to the long product development cycles. In thissituation, it takes several years to achieve the mature stageof the development process. It is interesting to note that theinitial phase of concept exploration, only 2% is conductedin cross-functional team settings!

This empirical observation in the aerospace industryraises important questions. If we know that a suppliers’involvement in the process of product development isimportant and if it leads to substantial positive outcomes,why is there a discrepancy between the arguments forincreasing supplier involvement and the empirical observa-tions indicating a low level of early involvement andsupplier integration across many development phases fromconcept to production and sustain engineering? Furtherquestions can be raised of how suppliers actually wereinvolved in the development process in these teamsindicating a low level of involvement. Were they only

observers, guests, or did they work as full team members?We can also ask whether the division of work betweensuppliers and systems integrator was mutually beneficial ora contradiction, whether they had the same mission andgoal in teams, and how workflow and organizationalroutines enhanced or obstructed the team-based work.

1.1. Supplier integration in the development of Saab 39

Gripen

The Swedish aircraft manufacturing company SaabAerospace AB has been developing military aircraft since1937 and has provided the Swedish Air Force with manydifferent aircraft. JAS39 Gripen is the first aircraft in thenew fourth generation of military aircraft such as theFrench Rafale, the US F-22 and the European Eurofighter2000. Approximately 3500 people are employed at Saab inthe development and production of military aircraft.Notably, Saab Aerospace is one of the smallest manufac-turers of high-tech military aircrafts in the world develop-ing and producing one of the most advanced aircrafts.There are only 3–4 competitors on the world market.The characteristic of the Gripen is its capability to

combine the roles of traditional fighter, attack, andreconnaissance aircraft. This combination of tasks createsgreat flexibility. To ensure flexibility and to accelerate fieldservice, the JAS39 Gripen carries an auxiliary power unit(APU). This consists of a small jet engine turbine installedin the rear airframe, which produces air pressure for enginestart, the electronics cooling system, and the emergencyelectrical and hydraulic power system. The completesystem is named APESS–Auxiliary Power Engine StartingSystem. Initially, the Gripen was designed to carry an APUdeveloped and manufactured by Microturbo in France.However, due to new environmental requirements estab-lished by the Swedish government, a new APU had to bedeveloped. After a period of discussions between Saab,Microturbo in France, and Sundstrand in USA, a decisionwas made at Saab that a new APU should be bought fromthe US supplier, Sundstrand. Due to a very demandingtime schedule, a concurrent engineering approach had tobe adopted in the development project. The strategy ofSaab was to move towards long-term oriented partnershipcollaboration on all corporate levels. On the strategic levelSaab and the supplier agreed to work in an integrated way.Several measures to ensure integration with the supplier

were taken. A special liaison engineer was located at thesupplier for the whole timetable of the project, numerousmeetings took place between people at Saab and atSundstrand, especially among management, special facsi-mile lines were introduced to enhance secure communica-tion, and mutual adjustment points were scheduled inorder to evaluate the progress of the project. Several Saabengineers were sent over to the supplier to coordinate workand occasionally some engineers from the supplier spenttime at Saab. However, on the operational, engineeringlevel the desired integration was not established. The

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257248

contractual forms between Saab and Sundstrand created anecessary basis for early involvement and integration ofsuppliers. Everybody wanted this. Top-level managers, aswell as project managers and engineers on different levels,at Saab and at the supplying company wanted it. Thedetailed product specifications clearly stated what thesupplier was expected to deliver. Despite that, lack ofcommunication about specifications, and the end-custo-mer’s usage of the aircraft increased uncertainty andambiguity. Interestingly, Saab and Sundstrand usedcross-functional teams at both locations, in Sweden andin USA, but none of these teams were inter-organization-ally integrated, in cross-functional teams. The level ofintegration in the operational level in the product devel-opment work was high within each company’s differentfunctions, and at the same time low between thecompanies. This situation created the basis for the lack ofcommunication and information exchange between peoplein the development of the new APESS.

To understand why engineers at Saab and at Sundstranddid not collaborate and communicate with each other asexpected on the operational level we must explore someimportant issues and prerequisites for engineering work. Inorder to perform product development in integratedsettings the engineering work has to be prepared for andplanned for being performed in cross-functional team. Thisis done by designing actions of engineers and componentsof the product architecture in suitable work packages (WP)that can be handled by teams in periods of 8–14 weeks. Theanalysis of the development work of the two seated JAS 39Gripen shows that structural aspects of product develop-ment, the design of the product architecture and develop-ment process, i.e. the design of the work breakdownstructure (WBS) and work packages (WP), was one of thekey elements to collaboration and communication betweendepartments at Saab. The successful development of thetwo seated JAS 39 Gripen was designed and carried out inmore than 400 integrated work packages (Danilovic, 1997,1999). However, when his analysis was extended andfocused on the early involvement and integration ofsuppliers in the APESS project the design of WBS andWP shoved to be the barrier to supplier integration as theywere done following the departmental logic at Saab and atSundstrand. The hypothesis underlying this article is thatthe design of the work breakdown structure (WBS) andwork packages (WP) are important issues in understandingwhy suppliers were not involved in product development asexpected and crucial if one desires high level of integrationto take place.

1.2. The aim and the outline of this article

The main focus in this article is to identify barriers tosupply integration and to develop an approach to enableearly supplier involvement and integration in productdevelopment on the operational, engineering work level incross-functional teams.

The purpose of this article is to investigate the impact ofthe work breakdown structure (WBS) and work packages(WP) in product development on the possibilities to carrythrough a strategy of supplier involvement into collabora-tive practice and to investigate how supplier involvementcan be improved by the design of collaborative WBS andWP structures. In this article I intend to show how analternative WBS and WP design that enables high level ofsupplier integration on the engineering level and indifferent phases of the product development.After a brief literature review as the introduction to the

issue, some aspects of supplier involvement and integrationwithin the aerospace industry are described. Particularlythe specific issues of the design of work break down (WBS)and work package (WP) are elaborated. To strengthen theanalysis of the empirical material and as the introductionto suggested methodological approach, relevant theoreticalliterature is presented in the area of managing complexsystems. Finally, in order to elaborate on the design of theWBS and WPs a new methodological approach isintroduced, Dependence Structure Matrix (DSM). Thisapproach is applied in one empirical case, on differentWBS levels and in different development phases.

2. Research approach

The general research approach underlying this article isaction-based research. The empirical investigation wasconducted in a longitudinal process, over a ten-yearresearch period, in close collaboration with Saab Aero-space. Formal interviews, informal conversations, partici-pation in the daily life of engineers and participation inmanagement teams were the primary methods in use. Themethod implies a great deal of what Glaser and Strauss(1967) call grounded theory as well as thoughts from theaction frame of reference of Silverman (1970). The specificempirical data in this article were based on 17 interviews, 7seminars, 4 workshops at Saab and one with Sundstrand,the supplier of APU from San Diego, USA, as well asextensive participation on an everyday basis. The metho-dology suggested here was elaborated during this researchproject and was carried out in close collaboration with top-level managers, project managers and engineers.The analyses of WBS and WP presented in this article

have been based on a dialogue situation between engineersand management from Saab and Sundstrand. The mainfeature of using a participatory approach is that theengineers and management are the main actors, definingtheir problems and participating in the creation of theproduct development process (Garnsey, 1992). When thisproject started, the chosen methodology (DSM as de-scribed in this article) was new to people at Saab. Later onSaab used the DSM approach in real life situations tochange WBS and WP structures. The action-basedapproach in this research made it possible to test, evaluate,and experiment with DSM approach to create structuralprerequisites in terms of redefining the WBS and WP

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 249

structures. The seminars showed that this DSM approachwas feasible, and suggested alternative WBS and WPdesigns which were practical from both Saab’s and thesupplier’s perspective.

2.1. Approaches to manage complexity

Complexity in product development can be understoodin terms of the variation of components in the productarchitecture, the number of different tasks in the develop-ment process, the number of people with differentprofessions and training involved in organizations, thenumber of different technologies used, and the amount ofrequirements to be met. Complexity stems from elementswith a multitude of relationships and dependencies, such asbetween people, their activities, and the components ofthe product, and the organizational and social context inwhich product development takes place. This implies thatcomplexity increases as the number of different organiza-tions are involved such as when suppliers are supposed tobe involved in product development (Simon, 1957, 1962,1969). The traditional approach to manage complexity of aproduct is by systematic decomposition of a product intocomponents and elements and by integrating componentsinto chunks and sub-systems. Every product has some kindof architecture. The purpose of the product architecture isto define the basic functional and physical building blocksand elements of the product in terms of what they do andwhat their interfaces are to the rest of the device. Productarchitecture is defined by Ulrich and Eppinger (1994) as‘‘the arrangement of the functional elements of a product into

physical blocks’’. A product can be seen in both functionaland physical terms. The set of functional elements of aproduct are the individual operations and transformationsthat contribute to the overall performance of the product.

Fig. 1. Managing complexity—the proces

The set of physical elements of a product are the parts,components, and subassemblies that ultimately implementthe product’s function. The physical elements of a productare typically organized into several major physical buildingblocks, which are called chunks. (Ulrich and Eppinger,1994, p. 131).The principles of decomposition and integration in

product development are shown in Fig. 1. (Based onPimmler and Eppinger, 1994, Ulrich and Eppinger, 1994.)This process of decomposition of a product architecture

and integration of components into subsystems is compar-able to the discussion by Lawrence and Lorsch regardingorganizational differentiation and integration (Lawrenceand Lorsch, 1967). In this approach, hierarchical structuresrefers to the decomposition of a complex system into astructured ordering of sets of subsystems, a partitioninginto relationships that collectively define the parts of anywhole system. The term ‘hierarchy’ is used by Simon (1957,1962, 1969) in a more general manner than is usuallyinvoked in organizational economics and organizationaltheory, where it typically denotes a relationship based onsubordination to authority.One approach in analyzing complexity and handling

ambiguity and assumptions, in order to reduce uncertaintyin decision-making, is based on a systematic analysis of thestructure of a system’s design based on its dependencies,the relations between items and the need for informationexchange between people regarding components in theproduct architecture, and their activities in the develop-ment process. Product development therefore requires,careful planning of the decomposition and integration ofcomponents, and coordination of people and integration oftasks within and between organizations such as systemsintegrators and suppliers. In industry in general, decom-position of the product architecture or task structure is

ses of decomposition and integration.

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257250

named Work Breakdown Structure (WBS). The combina-tion, or integration, of components into chunks andsubsystems is named work package (WP). Both of theseterms are practices and generally used in aerospace andautomotive industries. They are well documented inpublished material from, for example, the Project Manage-ment Institute (2000). Both WBS and WP are hierarchicalstructures; see Fig. 1.

The major issue here is related to the logics in the processof the decomposition of a product, from a higher systemlevel to its components and integration of componentsinto sub-systems and final product. In every system thatcontains a hierarchical structure of components, tasks, andpeople, there will be interfaces between them. The majorpoint in this article is the suggestion that alternativeapproach to integration, taking into consideration depen-dencies between components in the product architecture,tasks in the process, and between people in team settings, iscrucial to create prerequisites for high level of supplierintegration on the engineering cross-functional team level.

2.2. The dependence structure matrix (DSM) approach to

the design of the WBS and WP structures in product

development

Relations and dependencies between elements such ascomponents, activities and people are the major character-istics of complex systems. The approach to identify andmodel the dependencies in complex systems is known asDependence Structure Matrix (DSM). The DSM approachis based on a problem-solving analysis of relations,constraints, dependencies and assumptions in order todefine a problem (Steward, 1981). DSM represents andvisualizes relations and dependencies among tasks andactivities, components and subsystems, and among peopleand teams. DSM has been widely used in many differentindustries (Browning, 2001).

Fig. 2 shows the principles of matrix-based representa-tions (DSM) compared to a more traditional flowrepresentation. Fig. 2(a) shows a flow representation ofsix items and how they are related to each other. The sameitems from Fig. 2(a) are in Fig. 2(b) represented in amatrix. In a matrix based representation, relations between

Fig. 2. Flow and matrix representatio

items are plotted in rows and columns. The intersectionsbetween rows and columns contain the identified relationand dependency information.Fig. 2(b), DSM representation, reads from left to right

an items row to see its inputs and across its columns to seeits outputs (although the opposite convention, the trans-pose of the matrix, is also used). For example, the DSMmatrix in Fig. 2(b) shows item A receiving inputs from noother item while item B receives inputs from item A, item Creceives inputs from item A, and item D receives inputsfrom item B and provides an output to element F.A DSM analysis can be applied on components in a

product architecture, people in organizations, tasks inprocesses and those analysis can show how to designmodular structures, team-based organizations and con-current processes (Eppinger et al., 1994). The informationcaptured in a DSM analysis is similar to that in a directedgraph or a PERT chart, yet the matrix representationmakes it possible to create a complete model of informa-tion flow and dependency analysis in describing andanalyzing complex projects. DSM allows for tasks to becoupled or independent, unlike the PERT technique.

3. The case study

3.1. Organizing product development in the APESS

project—design of the work breakdown structure (WBS)

The design of the work breakdown structure (WBS) inthe decomposition of the product architecture in theAPESS project was functionally oriented, following thelogic of the basic functional organization at Saab andthe supplier. Fig. 3 shows the WBS of the APESS projecton four product levels.The decomposition process starts at WBS level 1, the

product level and continues to level 2—the subsystem level,level 3—the traditional work package level and finally level4—the component level. On the WBS level 2 the productcontains four major subsystems developed at Saab (nos.1–4), one major subsystem developed by the supplier (no.5), and one subsystem (no. 6) that contain time-criticalcomponents. The WBS on level 2 is identical to thedepartments at Saab, boxes with numbers 1–4 while the

n of relations and dependencies.

ARTICLE IN PRESS

Fig. 3. Work breakdown structure (WBS) in APESS on four levels.

M. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 251

box number 5 is supplier related and followed thedepartmental logic at Sundstrand. The WBS level 3 showsoriginal work packages (WP) that were departmentallydesigned, (example WP no. 1.3) within the Department ofEngineering, Installation, and Production. Due to the largenumber of components of the product architecture, Fig. 3shows limited number of components on WBS level 4.Overall, the processes of decomposition and integration inthe APESS project, at Saab and at the supplier, follow thesame functional logic. The consequence of this depart-mental logic in the decomposition and integration isobvious on WBS levels 3 and 4. The outcomes of thisprocess are functionally defined WBS and WP that doesnot take into Account the interdependencies betweenelements. This situation creates a clear separation betweenSaab and supplier, and therefore also low level ofintegration on the engineering level in the developmentwork.

What must be considered is that people in all these WPsperformed tasks that were dependent on each other,instead of being independent. Dependencies across ele-ments in the WBS and work packages were strong. Whenintegration with a supplier becomes a strategy, as it was inthe APESS project, this functionally and departmentallyestablished WBS and WP logic introduces barriers tocommunication as engineers did not know who was doingwhat and when. Few knew what kind of information othersneeded and who could provide them with the important

information they needed. Transparency and situationalvisibility were low. Those who created the work breakdownstructure see it as a highway, but those who have to workwith it do not necessarily hold the same view.One important lesson from the APESS project was that

if a higher level of integration was to be implementedbetween Saab and the supplier, the prevailing WBSstructure and WP had to be altered according to someother logic than the traditional functional logic.

3.2. Application of dependence structure matrix approach in

the APESS project

In this research DSM was applied on all four relevantWBS levels (WBS level 2–4) (Danilovic, 1999). However, inthis article only levels 2 and 3 are explored.

3.2.1. Dependence structure matrix analysis of the APESS

project on WBS level 2

Fig. 4 shows the initial DSM analysis performed onWBS level 2. The purpose of this analysis is to identify asmany interdependencies as possible between elements onthis level. To handle the dynamics of product development,a DSM analysis was conducted in each of the identifiablephases of development from the Concept phase, throughthe Development phase, Test and Evaluation phase,Production phase, to the Customer Support and SustainEngineering phase. Phases are identified according to the

ARTICLE IN PRESS

Fig. 4. Dependence structure matrix (DSM) analysis on WBS levels 2.

M. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257252

practice at Saab. The DSM analysis in Fig. 4 shows inwhich product development phase and the level ofinterdependence as it was perceived by participants. Thelevel of interdependence was estimated with numbers 1, 2,and 3, indicating low level of interdependence, medium,and high level of interdependence.

From Fig. 4 we can see that amount of interdependenciesare very large and that they occur in different developmentphases and with different levels of dependencies. Identifiedinterdependence is presented in Fig. 4 by its description,first letter of the phase and number indicating the level ofinterdependence.

What is important, from supplier integration perspec-tive, is that supplier related item A5 shows a large numberof dependencies to items A1, A2, and A4, which are Saabrelated items on WBS level 2. In other words, this showsthe interface between Saab as systems integrator andSundstrand as supplier. It is also noticeable that in the itemA5 engineers from Sundstrand identified a large number ofdependencies to Saab, much more than engineers from

Saab identified. This shows that engineers from thesupplier needed a large amount of information from Saabas systems integrator. The participatory approach, group-oriented process of information gathering and commu-nicating, involving debate and conversation about whodoes what, why, when and how, and what kind ofinformation they need. This conversation reveals relationsand dependence among components and tasks, what kindof dependence can be identified, what impact thisdependence has on all the people involved and their tasks,from different points of view. Finally, this conversationcreates a mutual understanding of how such dependence isto be handled. The participatory DSM approach createssituational visibility and thus reduces the perceiveduncertainty.

3.2.2. Dependence structure matrix analysis of the APESS

project on WBS level 3

The DSM analyses on WBS level 3 was more limited inits scope than the one performed on WBS level 2, presented

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 253

in Fig. 4. While the analysis on WBS level 2 identified asmany interdependencies as possible, the analysis on WBSlevel 3 focused the technical information exchange that wasneeded in order to enable engineering work.

In addition, the design of matrixes on WBS level 3 isdifferent than the matrix design on WBS level 2. On WBSlevel 3 the structure in Fig. 3 was used and elaborated inorder to identify elements within each box of the WBS onlevel 2. Fig. 5 shows DSM analysis of existing WBS andWP structure in the APESS project only in the conceptphase of the development process.

In Fig. 5 we can see on the left side the items on WBSlevel 3, following the departmental logic (See Fig. 3, WBSlevel 2). In the DSM matrix different dependencies areshown and numbers indicate the level of dependencebetween each item involved. Along the diagonal boxesare drawn in order to point out the existing WP structure.Those WP (chunks of elements) are defined by Saab aswork packages no. 1–5, as shown in the right part of Fig. 5.In accordance with Fig. 4, the interface between supplierrelated elements and the rest of Saab is significant. Fig. 5shows clearly that there are many important interdepen-dencies in between existing WPs, a large number ofdependencies with level 2 and 3 were pointed out. Someof those areas represent interfaces between establishedwork packages while others represent interfaces betweenSaab and Sundstrand. Those interfaces were not coveredby any work package. Before this DSM analysis wasperformed, neither interdependencies in general nor theinterfaces were identified, visualized, or communicatedamong people. The WBS and WPs design (Figs. 4 and 5)created a chasm and kept the supplier at arm’s lengthdespite the strategy of developing integration between Saab

Fig. 5. DSM—analysis on WBS-levels 3 ‘‘as-

and Sundstrand. If people are unaware of the interdepen-dencies and the information they need, how can we be surethat these unknown points of interaction in between WPswill not cause problems, delays, rework, etc.? The desirablestrategy needed to be supported by collaborative WBS andWPs. That was not the reality. This conclusion wassupported by individual interviews and in the workshops.

3.3. Towards integration between systems integrator and

supplier—formation of integrated work break down structure

(WBS) and work packages (WP)

Fig. 6 contains a modified DSM analysis, an alternativeto the established WBS design, based on the information inFig. 5. In Fig. 6 the same information is elaborated bymoving rows and corresponding columns in order to findclusters of interdependencies. This elaboration is intendingto define a number of clusters along the diagonal. Thoseclusters represent grouping of elements in the WBS on level3, potential integrated work packages both within Saaband with Sundstrand.In Fig. 6, new boxes are drawn along the diagonal line

indicating that some of the Saab related elements could begrouped together and some times grouped together withsupplier-related elements. Thus, this clustering along thediagonal shows that supplier elements could be integratedwith Saab-related elements in a collaborative WBS and fiveintegrated work packages, WP 1, WP2, WP 4 and WP5,were suggested. Only WP 3 was Saab related. Theseintegrated WPs represent integrated teams, breaking theestablished departmental logic in the decomposition andintegration of elements when new WBS and WPs aredefined. Theoretically, there may be a mathematically

is’’ disintegrated work package structure.

ARTICLE IN PRESS

Fig. 6. DSM—analysis on WBS-levels 3, integrated work package structure.

M. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257254

optimal point, but in practice, different solutions arepossible. The four inter-organizational, supplier-inte-grated, WPs and one, intra-organizational WP, are moreintegrated than before (compare Fig. 5 to Fig. 6). Fig. 6shows that no matter how rows and columns aretransformed, interfaces will always remain, be present,and must be handled. The APESS project is an example ofa high degree of dependence between most of thecomponents. In order to handle interfaces between systemteams, coordination teams are suggested.

3.4. Managing the integrated work break down structure

(WBS) and work packages (WP) in dynamic situations in

product development

As mentioned in the beginning of this article, earlysupplier involvement and high level of supplier integrationtakes place in few development phases. As shown inprevious analysis the way WBS and WPs are definedcreates prerequisites for the possibilities to integratesupplier in the process, particularly when this is a strategyon the engineering level. As seen in Fig. 4 the identificationof interdependencies explored not only the content ofinterdependencies, but also when it occurs and the strengthof the interdependence.

Fig. 7 shows the outcome of DSM analysis of all fivephases in the APESS project, Concept, Development, Testand Verification, Production and Sustain EngineeringPhase.

In each of those phases, rows and columns were alteredin the same way as in Fig. 6, in order to find the mostintegrated clusters along the diagonal. In each of thosefigures, boxes are drawn along the diagonal to show how

potentially integrated WPs could be designed. The boxesalong the diagonal in all DSM analysis in Fig. 7 suggest anumber of supplier-integrated WPs. In the Concept phasewe can identify 4 of 5 supplier-integrated WPs (also seen inFig. 6), in Development phase 3 of 5 WPs are supplier-integrated, and in Test and Evaluation phase all 5 WPs aresupplier-integrated, while in the Production phase only3 of 5 WPs are supplier-integrated, and in the SustainEngineering phase all 5 WPs are supplier integrated.We see in Fig. 7 that product development is a dynamic

process. The pattern of interdependencies varies from oneto another phase, from the concept phase to sustainengineering product development phase. The density inmatrixes, amount of interdependencies, is highest in thefirst three phases and substantially fewer are identified inthe two later phases. One conclusion is that the level ofambiguity is higher in the beginning, and that is muchmore information that needs to be handled, shared anddistributed between system integrator and supplier.One consequence of this finding is that the design of WPs

needs to be different in different phases, if high level ofsupplier integration is the strategy. This implies that suchproposed DSM analysis has to be done at several occasionsduring the process of product development.

4. Conclusions

Although both corporations, Saab Aerospace andSundstrand, have developed a mutual strategy stressingearly supplier involvement and integration, it was notachieved on the operational levels due to the fact thatstructural prerequisites on the project and team level didnot support the overall business strategy. The logic in the

ARTICLE IN PRESS

Fig. 7. DSM—analysis in 5 products development phases.

M. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 255

design of the work breakdown structure (WBS) and workpackages (WPs) was traditionally designed on a functionalbasis reflecting the prevailing organization and did notsupport the strategy. The consequence was low transpar-ency, low situational visibility, lack of communication, lackof integrated tasks and activities, and weak understandingof what the process of product development means toengineers within and between corporations.To achieve the strategy of a high level of supplier

integration on project and team levels, alternative logic hasto be adopted focusing on interdependencies and informa-tion flow between people in both companies. Dependencestructure matrix (DSM) methodology is introduced toelaborate and to design collaborative WBS and integrativeWPs. DSM analysis showed that collaborative WBS andintegrated WPs could be developed in five different productdevelopment phases, creating prerequisites for intra-cor-porate integration of functions within Saab Aerospace andinter-organizational integration with Sundstrand. Suchintegrative WPs can support the strategy of supplierintegration in project and cross-functional teams. TheDSM analysis shows also that no matter how integratedWPs are designed there will always be interfaces that needto be handled. Therefore coordination team structure,linking pins, might be applied to handle interfaces betweenintegrated WPs.Integrated WPs enables that communication, and the

information exchange, mutual understanding is obtainedon the individual level in both companies. The outcome isincreased transparency and situational visibility. DSMcreates an arena for communication between technicaldisciplines, between management and engineers, systemsintegrator and suppliers, which is otherwise missing. DSMenables communication through handshaking and byformalizing informal communication and informationexchange. DSM provides feedback mechanisms whendiscussing the past, present, and future. This feedbackprovides information on and knowledge of past projectsand experiences, problems and lessons, goal-seekinginformation on the project, its milestones, and conse-quences for engineers, systems, and engineering teams andcorporations, economic restrictions, the consequences andinterpretations of technical specifications and require-ments, etc.

4.1. Implications for managers

If management has a strategy to achieve early supplierinvolvement and integration the WBS and WP has to beredesigned from the very beginning of the developmentprocess, i.e. projects, in order to design integrative WP.Therefore, DSM approach has to be used very early in thisprocess. As the product development is a dynamic process,DSM approach has to be used at different occasions andsituations.To enable early adaptation of DSM approach top level

managers have to be committed to such approach, creating

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257256

an arena where such methodology is used, is accepted, andapproved by top management. In addition, the outcome ofsuch analysis indicates how the old structures need to bechanged in order to create prerequisites for supplierintegration. Management has to be committed to carrythrough the strategy in the design of WBS and WP. If not,the strategy will remain to be a strategy while engineeringpractice will be very different.

This approach to DSM focuses on important managerialaspects of creating prerequisites for handling the uncer-tainty, the unpredictable factors, which always characterizecomplex product development. Management and engineersneeds to find an opportunity to analyze a project accordingto its mission, goals, and restrictions. When these aspectsare discussed, management and engineers can mutuallyshape an appropriate strategy for conducting tasks basedon a common understanding and acceptance of conditionsfor the project. This process is labelled by Westley (1990) asstrategic conversation and micro dynamics of inclusion. Inaddition, management and engineers can together designappropriate structures and processes. The subjectivity inthe actor approach becomes a line of action (Garnsey,1992).

4.2. Limitations of chosen approach

The DSM approach used in this research gives a staticpicture of interdependencies and the need for informationexchange at the time of the investigation. DSM approachhas to be used as a flexible approach, repeated asinterdependencies changes over time as the productdevelopment is a dynamic process. DSM should not beused as a static approach but an approach that reflects thedynamics.

In order to support practitioners practical tools need tobe developed that helps practitioners to do DSM studies ina simple way. In my research I have developed suchsoftware tool that was used in this article.

4.3. Future research

Managing product development means that severalaspects of complexity and uncertainty have to be handledsimultaneously. The supplier integration in integrativeorganizational settings, process design enabling earlyinvolvement, and supplier integration in a modularproduct architecture stress that all domains have to bedesigned in a way to support each other. Integration ofsuppliers requires that all those domains have to beconsidered and managed. This article put focus on theimpact of the design of WBS and WP in the productarchitectural domain. It is therefore important thatapproaches and tools that can support the dynamics ofproduct development were focus is on the glue, i.e. the flowof information within and between those domains reflect-ing the dynamics of the product development process.

Acknowledgements

I would like to express my gratitude to two anonymousreviewers for their valuable comments on earlier versions ofthis article.

References

Backhouse, C., Brooks, N., 1996. Concurrent Engineering–What’s

Working Where, The Design Council. Aldershot, Gover Publishing

Limited.

Bonaccorsi, A., Lipparini, A., 1994. Strategic partnership in new product

development: an Italian case study. Journal of Product Innovation

Management 11, 134–145.

Borjesson, H., Boden, S., Haglund, L., Nielsen, A., Ahlgren, F., 1996.

TFL projekt FEM 43 Samordning Inkop Saab. Saab Aerospace

report, Linkoping.

Browning, R.T., 2001. Applying the design structure matrix to system

integration and decomposition problems, review and new directions.

IEEE Transactions on Engineering Management 48(3).

Clark, K.B., Fujimoto, T., 1991. Product Development Performance:

Strategy, Organization and Management in the World Auto Industry.

Harvard Business School Press, Boston, MA.

Danilovic, M., 1997. Tvardrag—integrerad utvecklings- och produktions-

verksamhet genom tvarfunktionellt arbetssatt. Department of Man-

agement and Economics, Linkopings universitet, Linkoping.

Danilovic, M., 1999. Loop-leadership and organization of integration in

product development. Dissertation, Department of Management and

Economics, Linkopings universitet, Linkoping.

Eppinger, S.D., Whitney, D.E., Smith, R.P., Gebala, D.A., 1994.

A model-based method for organizing tasks in product development.

Research in Engineering Design 6.

Fruin, M.W., 1992. The Japanese Enterprise System. Oxford University

Press, New York.

Garnsey, E., 1992. Critical Systems Thinking as an Integrative Perspective

in Social Theory. University of Cambridge, Cambridge.

Glaser, B.G., Strauss, A.L., 1967. The discovery of grounded theory.

Adline Publishing Company, Chicago.

Klein, A.J., Susman, G.I., 1995. Lean Aircraft Initiative Organization &

Human Resources (O&HR) Survey Feedback—Integrated Product

Teams (IPTs), Lean Aircraft Initiative, White Paper-Lean 95-03.

MIT—Massachusetts Institute of Technology, Boston.

Lamming, R.C., 1987. The International Automotive Components

Industry; Customer-Supplier Relationship: Past, Present and Future.

MIT—Massachusetts Institute of Technology, Boston.

Lamming, R.C., 1989. The International Automotive Components

Industry; The Next Best Practice for Suppliers. Massachusetts Institute

of Technology, Boston.

Lamming, R.C., 1993. Beyond Partnership. Prentice-Hall International,

Hertfordshire.

Lawrence, P.R., Lorsch, J.W., 1967. Organization and Environment:

Managing Differentiation and Integration. Harvard University,

Boston.

Lyons, T.F., Krachenherg, T., Henke, J.W., 1990. Mixed motive

marriages: what’s next for buyer–supplier relations? Sloan Manage-

ment Review 31 (3), 29–36.

Pimmler, T.U., Eppinger, S.D., 1994. Integration Analysis of Product

Decompositions. ASME, Design Theory and Methodology—DTM, 94

68, 343–351.

Project Management Institute, 2000. Practice Standard for Work Break-

down Structures. PMI Inc., Pennsylvania.

Quinn, J.B., 1992. Intelligent Enterprise. The Free Press, New York.

Silverman, D., 1970. The theory of organizations. Heinemann, London.

Simon, H.A., 1957. Administrative Behavior: A Study of Decision-

Making Processes in Administrative Organization. 2nd ed. The Free

Press, New York.

ARTICLE IN PRESSM. Danilovic / Journal of Purchasing & Supply Management 12 (2006) 246–257 257

Simon, H.A., 1962. The Architecture of Complexity. Proceedings of the

American Philosophical Society 106, 467–482.

Simon, H.A., 1969. The Science of the Artificial. MIT—Massachusetts

Institute of Technology Press, Boston.

Steward, D.V., 1981. The design structure system: a method for managing

the design of complex systems. IEEE Transactions on Engineering

Management 28(3).

Ulrich, K.T., Eppinger, S.D., 1994. Product Design and Development,

Editions. McGraw-Hill International, NewYork.

Weiss, S.I., Murman, E.M., Ross, D., 1996. The Air Force and Industry

Think Lean. AIAA—Aerospace, America.

Westley, F.R., 1990. Middle managers and strategy: micro dynamics of

inclusion. Strategic Management Journal 4, 337–351.

Womack, J.P., Jones, D.T., 1994. From lean production to the lean

enterprise. Harvard Business Review 72 (1), 93–103.

Womack, J.P., Jones, D.T., Ross, D., 1990. The Machine That Changed

the World—The Story of Lean Production. Harper Collins Publica-

tion, New York.