Interorganizational IT Support for Collaborative Product Development

(1)

Linköping Studies in Management Dissertations from the International and Economics, Dissertations Graduate School of Management and

No. 54 Industrial Engineering, IMIE

No. 59, Doctoral Dissertation

Interorganizational IT Support for

Collaborative Product Development

Anna Öhrwall Rönnbäck

2002

Department of Management and Economics Division of Industrial Management and Economics

(2)

ISSN: 0347-8920 ISSN: 1402-0793

Printed by: UniTryck, Linköping Distributed by:

Linköpings universitet

Department of Management and Economics SE-581 83 Linköping, Sweden

(3)

(4)

(5)

Acknowledgments

First and most of all I would like to thank my supervisor Professor Staffan Brege for making it all possible by recruiting me to the research school IMIE back in 1997. Thanks for everything, Staffan, from insightful theoretical discussions, to supportive and inspiring talks when I needed them most!

My gratitude also goes to Professor Staffan Gullander for his creative new ideas and constructive criticism of my work, and for good companionship in our “joint ventures”. I also thank Professor Mats Abrahamsson for sharing his ideas on the IT puzzle, his fast reading, and always valuable and encouraging comments. Thanks also to Hugh Excell for excellent proofreading and in other ways improving the readability of this dissertation.

Special thanks also to UniTryck for keeping track of files and for a flexible and fast job printing this book.

Over the years many skilled people have kindly read and commented on my work. Thank you Dr Johan Lilliecreutz, Tech lic Gunnar Holmberg, Dr Roland Sjöström, Dr Mats Björkman, and Dr Jakob Gramenius, for proficient help with the licentiate thesis. Thank you Dr Jonas Herbertsson, Dr Mike Danilovic, and Associate Professor Helén Andersson for important comments on previous versions of this dissertation. Moreover, I have learnt a lot from my coauthors; thank you Dr Nicolette Lakemond (the early works), Tech lic Göran Backlund, MSc Helena Wennberg, Tech lic Peter Cronemyr and Professor Steven Eppinger. Many other people have helped me on the way – thank you all at ENDREA and IMIE.

There can be no product development research without product development cases. My deepest thanks to all respondents at Saab, Microturbo, Sundstrand Power Systems, Boeing, ABB Ventilation, FMV,

(6)

Fält Elektronik, and the firms connected to PUCK, SLIT, and the VMU, for letting me share your experiences and for taking your time. Here I also want to mention former colleagues in product development teams at Steelcase Strafor and DECIM who taught me a lot about product development work in practise that has been so useful for this research. And there is no good research without fun, which is yet another advantage of research in teams (that I forgot to mention in the method chapter)… Thank you all for the great memories of LARP and NISAM!

Financial support for the research has been received from the Swedish Foundation for Strategic Research (supports IMIE), NFFP (supported the “Lean Aircraft Research Project” together with Saab and the research schools IMIE and ENDREA), and NUTEK (supported the project “Ny Industriell SAMverkan”, managed by the IVF). I am grateful for their support.

I would also like to thank my colleagues at the Department of Economics and Management for their constantly present support and help. I can’t mention everyone by name but I want to thank especially MSc Helena Wennberg, Kicki Dahlberg, Dr Maria Huge Brodin, Dr Per-Olof Brehmer, Dr Jakob Rehme, and everyone at the “dynamic” division Industriell ekonomi for making it such an inspiring workplace!

Finally, I dedicate this work to those who mean most to me, my wonderful (extended) family: Karolina, Viktor, Niklas, Zoot and Foggy, Gudrun and Birger, my parents, and sisters. Thank you for giving me all the time I needed to finish it. We have a lot to catch up now!

Redinge Lillgård, March 2002

(7)

1 Introduction

This chapter serves as an introduction to the research area. The first section gives a background to the research problem. Then, the purpose and research questions are presented, followed by an overview of the structure of the thesis.

1.1 On Collaborative Product Development

Information management in product development is a delicate task since much is unknown both of market and technological aspects when a new product is being developed. Given that a large part of the product life cycle cost is determined already in the concept phase1_{, many variables and viewpoints need to be taken} into account. Representation of several company functions is necessary for requirement specification, knowledge acquisition, and decision-making concerning the forthcoming product throughout the development project. This cross-functional integration is generally referred to as integrated product development, IPD (Andreasen and Hein 1987), commonly organized as projects with integrated product development teams, IPTs, where representatives from eg marketing, R&D, and manufacturing departments take part (Wheelwright and Clark 1992).

In this research we add a dimension to the complexity of product development activities by studying interorganizational product development, ie when firms collaborate in the development of a common system. Collaboration in product development is increasingly common as a consequence of more complex products and globalization of business activities. Intensified competition

1_{Boeing reports that 80 % of the product costs are locked in by the product definition (Coyle}

et al 2000, reports from LAI-LEM, Lean Aerospace Initiative – Lean Enterprise Model, see REF-LAI).

(10)

has led to more frequent product launches, which have resulted in higher pressure on time to market and faster product development cycles. Moreover, local presence on several markets is often required in order to understand customers’ varying demands. (Nishiguchi 1996) Increased product complexity is a consequence of more advanced technology, for example the fast development of electronics, increased computerization, and materials development. Fine (1998) found that it is appropriate to talk about different clockspeed for different industries. Many products today are also so-called system products composed by several parts (subsystems) that shall function together as a whole (Rechtin 1993).

To develop products in this new competitive landscape (Bettis and Hitt 1995) requires competencies over a broader range than a firm usually can have in-house, and leads to larger development risks than most firms can bear on their own. Collaboration with other parties in the supply chain and with former competitors has therefore become a common solution. Examples of cases can be found eg in the aerospace industry studied in this research, in

Europe the Airbus consortium2_{and Saab’s close collaboration}

with former competitor British Aerospace, and, in the US, the development of the Joint Strike Fighter3_{. This increased} “co-opetition” (Nalebuff and Brandenburger 1996) is a consequence of the previously mentioned higher product complexity in combination with tougher competition (and in the defense industry lower military budgets, see Augustine 1983), which has led to reduced margins.

In fact, buyer-supplier cooperation in highly complex product development has a long tradition, for instance in the aerospace, automotive and medical industries. A change in recent years though is towards a more differentiated attitude to suppliers depending on the long-term strategic importance of their involvement (Kraljic 1983, Lilliecreutz and Ydreskog 1998), and a focus on the relationship between the collaborating parties (Lamming, Cousins, and Notman 1996). When large manufacturing firms seek to reduce their supplier base in order to be able to manage closer relationships with a few, strategic

2_{With British Aerospace, Aerospatiale-Matra, DaimlerChrysler Aerospace, CASA, and others,}

see www.airbus.com.

3_{See www.jast.com. Joint development between Boeing Lockheed Martin, McDonnell Douglas,}

(11)

suppliers, they become systems integrators instead of ordinary manufacturers, with responsibility for the overall quality and functionality of a product consisting of subsystems delivered from major systems suppliers with whom they work closely (Fredriksson 1994, Lilliecreutz 1996), as illustrated in figure 1.1.

Figure 1.1 Development of a system product often means to integrate system parts, which major suppliers develop and produce.

Closer vertical cooperation between a buyer firm and its major suppliers can be regarded as a threat for smaller firms, which risk being pushed backwards in the supply chain. However, by joining their forces in supplier networks (Womack, Jones, and Roos 1990 and Miles and Snow 1994), several component suppliers can offer complete system products either to buyer firms or to the first and second tiers in the supply chain. Such horizontal supplier network product development collaboration is usually organized to serve one customer firm. Most often, this customer firm initiates the product development assignment, although the contrary may be found (as in one of the supplier network cases studied, where the supplier network initiated the development4_{). Within the supplier} network, firms may also have some vertical buyer-supplier relations between them.

Innovations carried out together with customers, major suppliers and subtiers lead to increasingly complex supply chain cooperation (Quinn 2000). Compared to in-house development,

4_{The weapon lock case, see Appendix B.}

System Product 1st_{tier supplier}

1st_{tier supplier} ₁st_{tier supplier}

1st_{tier supplier} Systems integrator System Product 1st_{tier supplier}

1st_{tier supplier} ₁st_{tier supplier}

1st_{tier supplier}

Systems integrator

(12)

collaborative product development also sets higher requirements for communication management, where the balance between necessary openness concerning information sharing and precautions to control proprietary information is delicate (Biemans 1995, Parker 2000). Conclusions on the need for improved information management between collaborating partners is found in several previous research studies in this area (eg Bruce et al 1995, Ragatz et al 1997, Wynstra 1999, Chandrashekar and Schary 1999, Christopher 2000, Quinn 2000, Sawhney and Prandelli 2000), and has probably played a part in increasing expectations of the effect supporting IT tools could have.

Results from the empirical studies that this thesis is based on, show that until today mainly e-mail messages with attachments have been used for distant communication between engineers in different companies (see Appendix A – a study conducted of dyads in the aerospace industry, and Appendix B – a study of supplier networks in various industries). Is it that companies have not yet adopted the new technology, or do we have other fundamental barriers exist that prevent a more widespread use of interorganizational IT support in collaborative product development? This thesis shall further investigate the requirements for internet and web-based solutions for collaborative product development activities, the potential of such tools, and interorganizational barriers against use and implementation.

1.2 Purpose,

Research

Questions and Scope

1.2.1 Purpose

The objective of this thesis is to assess characteristics of communication in collaborative product development, in order to identify requirements for supporting IT tools.

The first part of the purpose, to assess characteristics of collaborative product development, implies to investigate special characteristics of communication and information exchange when two or several parties conduct product development together. The second part of the purpose is directed towards specifying a systems solution that can improve efficiency and effectiveness of collaborative product development.

(13)

1.2.2 Research Questions

Product development is an information and communication intense activity (Clark and Fujimoto 1991). When more than one firm is involved, questions linked to business aspects regarding what information to share and how to communicate the information between the firms become important (Fulk and DeSanctis 1995). Technological solutions for information and communication over company borders, referred to as interorganizational information systems (IOIS5_{), are therefore} considered relevant to study, however, not from a purely technological view. Also business aspects of interorganizational character must be considered in the search for explanations and explanatory models concerning IT tools for collaborative product development. Therefore, this thesis addresses the following three research questions:

1. What are the special characteristics of information and

communication in collaborative product development compared to intraorganizational product development?

2. What are the needs of IOISs for collaborative product development and what are the barriers against implementation and use? 3. What are the requirements for an IOIS so that it shall contribute to

rendering the collaborative product development process more efficient and effective in all phases?

IT tools and platforms for product development are extensively used in-house but not with external parties. The first research question therefore seeks to clarify differences between intra- and interorganizational product development activities, since it is believed that the special characteristics of collaborative product development can give explanations to this observation, and that a better understanding of communication in collaborative product development can lead to suggestions for improvements (called for by several authors in previous research, eg Bruce et al 1995). Previous research on collaborative product development mainly concerns dyads, where a supplier is involved in a focal firm’s intraorganizational product development, and takes one firm’s

5_{Both “IOIS” and “IOS” are used in previous literature for IT solutions for interorganizational}

cooperation. Here the terms IOIS will be used, since IOS (interorganizational system) can mean any system, not necessarily information system. The IS referred to in IOIS is an IS/IT system, ie based on information technology.

(14)

perspective (Håkansson 1987). This study investigates collaborative product development both in dyads and in supplier networks (where several firms take part), and is viewed from the buyer as well as from the supplier side. To include both dyads and supplier networks was considered important in order to be able to distinguish special conditions for collaborative product development compared to intrafirm development. A holistic view on buyer-supplier interaction is also encouraged by Melin (1989), in order to increase understanding of the “field-of-force” in an industrial field. Further, in studies of interorganizational activities, the relationship between the parties is central (Lamming, Cousins, and Notman 1996), and consequently to investigate the research questions from both buyer and supplier side was considered to give a more holistic picture of the problem than if the collaborative activities are one-sidedly studied.

The second question, mapping the needs of and barriers against information management with IT tools, is closely linked to the special characteristics of information and communication in collaborative product development in the first. The results of the second research question, in turn, could serve as a base for answering the third, which deals with identification of requirements for IOISs for product development. It seeks to list requirements for supporting IT tools that a firm could use if it takes part in collaborative product development either as a buyer or a supplier, and is therefore more of a normative character.

1.2.3 Scope – Limitations of the Thesis

The type of product that is studied has importance for the outcome of a study in product development (Eisenhardt and Tabrizi 1995). In this research, the development of physical products that are built up from mechanical or electronic parts has been studied. The literature focused on is therefore in the traditional product development field, not mainly in software development. In this regard, the thesis is close to the studies in the automotive industry as made by eg Clark and Fujimoto (1991), who limit their studies to tangible products. The theoretical framework is however not limited to the extensive amount of auto-industry studies (Womack et al 1990), but ranges over a large number of industries (IT and telecom, textile, and biotech).

The collaboration between firms studied is limited to business collaboration, ie that a business assignment is the major driving

(15)

force behind the collaboration, different from completely social networking (although business networking also often contains some social aspects, Melin 1989). Moreover, the study focuses on collaboration between business partners, as opposed to cooperation with other non-profit organizations such as universities or research centers (although such organizations may have some minor part in the cases studied, as described in Appendix B).

A firm’s development activities are generally referred to as Research and Development, R&D. While research refers to long-term explorative activities not aiming to develop a specific product, development refers to the relatively short-term innovative activities, which aims to develop a specific product for a specific market launch (Wheelwright and Clark 1992). The connection between a firm’s research and development is that research results generally lead to product development projects. This thesis focuses on the development activities.

Concerning the IT tools, the focus lies on IOISs based on internet technology. Moreover, originally the research questions also included long-term effects of using IOISs for collaborative product development. However, empirical limitations have led to this aspect not being studied. Instead, the study of the long-term effects of IOISs is suggested for further research.

1.3 Structure of the Thesis

This introductory chapter has presented the area of interest, the purpose and the research questions. Chapter 2 contains a description of the research methodology. Chapter 3 gives a brief theoretical background and definition of key concepts to the problem area, but theoretical background is also described for each appended paper (Appendix A-C). Chapter 4 presents findings concerning critical issues for collaborative product development, largely based on the findings presented in Appendix A and B (and to some extent in Appendix C).

Needs for and barriers against use of information systems (IOIS) for collaborative product development are discussed in Chapter 5. The discussion mainly derives from the results presented in Appendix C. Finally, chapter 6 concludes the thesis by discussing

(16)

how an IOIS could be realized according to the requirements of Appendix C, and suggestions of further research.

(17)

2 Research Method and

Research Design

In this chapter the research strategy is described and a detailed description of the research process is given. Further, selection of cases is presented together with tactics for data collection, data analysis and theory generation. The chapter concludes with reflections on quality measures for the kind of study conducted for this research.

2.1 Methodological

Approach

The research problem presented in this thesis emanates from problems identified in business practice (eg Johnson 2000). Its specific focus on collaborative product development and internet applications makes it relatively new as a research area. Since the problem studied stretches over several areas such as integrated product development (engineering management), interfirm business

organization (business strategy, strategic purchasing, and

interorganizational relationships), and supporting information technology tools (IT management), it could be characterized as interdisciplinary and relatively complex.

The research strategy to apply to this kind of study can be discussed. According to Yin (1989) a researcher’s choice of methodological approach in social science research depends on the problem at hand and the control that the researcher has over the behavioral events. He suggests to choose case study method as a research strategy, as opposed to experiments and surveys, when

a ‘how’ or ‘why’ question is being asked about a contemporary set of events, over which the investigator has little or no control

(18)

To conduct a case study was an early choice in this research, due to the novelty of the problem area and the complexity with several theoretical disciplines involved (Eisenhardt 1989). The study contains also elements of action research where the role of the researcher lies in between the role of researcher and consultant (as described by Gummesson 1988).

The choice of research strategy is also based on the researcher’s personal preferences. At the beginning of this research, my personal preference was to conduct a comparative multiple case study with more the character of survey, with several empirical cases and essential quantitative parts (in the direction of a multiple case study within operations management as described by eg Lewis 1998). However, the initial empirical studies revealed that such a research strategy would be difficult to carry out in this field due to the problem characteristics: its novelty, its complexity, and consequently the difficulty for the researcher to control the course of events. Eisenhardt (1989) adds to this argument that a case-oriented research process is considered appropriate in new topic areas. Since case studies typically combine several data collection methods, such as archives, interviews, questionnaires and observations, and thus permit analysis of both qualitative and quantitative data, I found this method appropriate both due to the problem at hand and appealing from a personal point of view. Moreover, case studies can be applied for various aims; descriptive, theory testing or theory generating (Eisenhardt 1989). This research aims to be theory generating, but hopefully the descriptions of the case studies (in Appendix A and B) will also make relevant research contributions.

The importance of a rather well specified initial research question is valuable for systematic collecting of specific kinds of data (Mintzberg 1979). Early theoretical constructs are also important for a study, since it can contribute to more accurate and precise measurements. This is acceptable as long as the researcher recognizes that the possible constructs are only tentative and that the research question may change during the study (Eisenhardt 1989). Otherwise, the ideal of starting from “a clean theoretical slate” and avoiding thinking too much of relationships between variables and theories should be striven for at the outset of a study that aims to be theory building, since expected theoretical perspectives or propositions may interfere with the findings (Glaser and Strauss 1967, Eisenhardt 1989). My opinion is though,

(19)

that some theoretical insights in the area are necessary for forming better research quality and gain an awareness that helps avoid the risk of coming up with theoretical constructs that already exist (in accordance with Lewis 1998, Alvesson and Sköldberg 2000).

2.2 Research

Process

The research process is illustrated in figure 2.1. It has been iterative, with constant interplay between empirical data and theory. All along the data collection phases, reading and writing have been an integrated part of the research. (See list of previous publications from 1997-2001 in Appendix D.)

Figure 2.1 The research process

The research set out as an exploratory study, in order to get acquainted with the empirical phenomenon studied. This first part was carried out in a methodological approach influenced by grounded theory (Glaser and Strauss 1967, Strauss and Corbin 1990), with the objective of generating theoretical questions. At the outset of this research, a study with the research question to compare the formal product development process as described by a case company with the applied product development process, and to map the use of IT tools was conducted at one case company (Saab AB, reported in Andersson, Backlund, Cronemyr, Pohl, Sveder, and Öhrwall Rönnbäck 1998). RESULTS Theoretical contributions Managerial implications Current IT tools in product development The product development process Functions of an IT tool for collaborative product development The collaborative product development process

Three dyad cases (international aircraft

industry) IT (internet) projects (in the aircraft industry)

Integrated product development Collaborative product

development IT management

Three network cases (Swedish industry) Implementation of a web-based infrastructure Supply chain management (SCM) Buyer-supplier relationships Interorganizational information systems

Empirical data Theory

Appendix A Part I Part II Appendix B Appendix C Dissertation RESULTS Theoretical contributions Managerial implications Current IT tools in product development The product development process Functions of an IT tool for collaborative product development The collaborative product development process

Three dyad cases (international aircraft

industry) IT (internet) projects (in the aircraft industry)

Integrated product development Collaborative product

development IT management

Three network cases (Swedish industry) Implementation of a web-based infrastructure Supply chain management (SCM) Buyer-supplier relationships Interorganizational information systems

Empirical data Theory

Appendix A Part I Part II Appendix B Appendix C Dissertation

(20)

This initial study was important for the continued research, as it revealed empirical evidence concerning the involvement of suppliers and close collaboration with customers and other parties in complex system product development, which became central in the continued research. This was also something that I had experienced as a practitioner of product development6_{. The} pre-understanding I gained before and during the study of empirical areas and theoretical areas is shown in the chart in figure 2.1 (the “clouds” to the left).

After the initial intrafirm study (fall 1997), three in-depth case studies of interorganizational product development were carried out (1998-1999) at one firm and its major suppliers (Saab AB and suppliers Microturbo and Sundstrand). In the licentiate thesis, Appendix A, the empirical findings were related to previous theoretical findings, mainly in three areas: integrated product development, collaborative complex system product development, and IT management. The first part of the study can be classified as mainly inductive, ie it generates theoretical problems, as presented in Appendix A (see also Backlund and Öhrwall Rönnbäck 1998, and Cronemyr, Öhrwall Rönnbäck, and Eppinger 2001).

The theoretical findings and conclusions drawn in Part I were used to design the study and formulate questionnaires for Part II of the research. Part II was therefore of a more deductive character since the theoretical issues generated from the first part were used as a base for data collection.

The first empirical results of Part II (fall 1999) led into further readings of previous work in the areas of buyer-supplier relations, supply chain management, and interorganizational information systems (IOIS), as illustrated in figure 2.1. The complementary data collection carried out (fall 2000) was therefore much influenced by the empirical as well as the theoretical results so far, and led to more precise question areas in the last round of in-depth interviews. The second part resulted in Appendix B (see also Öhrwall Rönnbäck, Gullander, Brege 2001, and Pilemalm, Gullander, Norling, and Öhrwall Rönnbäck 2001).

6_{My personal prior experience of product development work consists primarily of}

participation in an international project team for the development of an office furniture system for the European market in 1993-1994 (see final product TNT by Steelcase Strafor, www.steelcase-strafor.fr), and participation in the development of a dental CAD/CAM system 1994-1997 (see final product DECIM and DENZIR at Decim, www.decim.se).

(21)

In Appendix C the empirical data from Part I and Part II is analyzed from an information and communication angle, while Appendix A and B described and analyzed the cases from a broader collaborative product development point of view.

2.3 Selection of Cases and Data Collection

The research design for case studies should be kept open for changes due to emergent results along the studies. Yet, this flexibility to complement initially selected cases should not be confounded with a shift in underlying theoretical objectives, which should be avoided in order not to make the study fit the cases found. (Yin 1989) Research tactics concerning how openness and flexibility was handled in this research will be accounted for in this section.

Since the researcher only can study a limited number of cases in-depth, case selection is central and should not be done at random. First, it is important to select an appropriate population among which the cases are selected. Definition of the population controls unwanted variation and gives the limits for generalizing from the cases. (Eisenhardt 1989) In this research, a specification of the population is “collaborative product development of physical products”. Studies of IT support in the collaboration (especially web-based tools) were conducted as a special track of data collection, connected to these product development cases. An overview of the cases studied in chronological order is given in figure 2.2. (See also table 2.1 below).

(22)

Figure 2.2 Overview of empirical studies carried out showing population and chronological order of the two parts.

In a multiple-case study the selection of cases should be done in order to reach a desired theoretical sampling (Glaser and Strauss 1967), ie it could include polar type cases and extreme situations that fill certain theoretical categories or extend the emergent theory7_{. In this research, the tactic was to complement an initial} study mainly carried out at one firm (in Part I) with a multiple case study (in Part II) that could extend emergent theory. Thus the multiple cases were not selected at the outset of the study, but were chosen at the end of Part I.

2.3.1 Case Selection Part I

Theoretical categories initially taken into account were, for the product development track in Part I, outsourcing of innovation activities and product complexity. The population was defined as product development carried out by a major supplier, studied from the buyer’s (systems integrator) perspective. The buyer and major suppliers studied were relatively large firms. The cases chosen were the development of two of the major systems (the auxiliary power and engine starting system, APESS, and the general electronic control

7_{As opposed to statistical sampling where random cases are selected from a larger population.} Ventilation control system

ABB - SLIT Ventilation control system

ABB - SLIT

Jan Jun Jan Jun

APESS 328 Saab-MT APESS 328 Saab-MT New APESS Saab-SPS New APESS Saab-SPS Jan Jun 1997 1999

Jan Jun Jan

Sweden-USA Sweden Platelet meter Fält Elektronik - PUCK Platelet meter Fält Elektronik - PUCK Web-based platform www.puck.se Web-based platform www.puck.se 1998 2000 2001 Sweden-France Sweden Part I: Saab and Major Suppliers

Weapon lock FMV- VMU Weapon lock FMV- VMU Sweden IT projects at Saab EMPIRE, PAM, VEGA

IT projects at Saab EMPIRE, PAM, VEGA

GECU Saab-ESB

Part II: Supplier Networks

Sweden Product development process

Saab

Product development process Saab Collaborative product development of physical products IS/IT projects

Ventilation control system ABB - SLIT Ventilation control system

ABB - SLIT

Jan Jun Jan Jun

APESS 328 Saab-MT APESS 328 Saab-MT New APESS Saab-SPS New APESS Saab-SPS Jan Jun 1997 1999

Jan Jun Jan

Sweden-USA Sweden Platelet meter Fält Elektronik - PUCK Platelet meter Fält Elektronik - PUCK Web-based platform www.puck.se Web-based platform www.puck.se 1998 2000 2001 Sweden-France Sweden Part I: Saab and Major Suppliers

Weapon lock FMV- VMU Weapon lock FMV- VMU Sweden IT projects at Saab EMPIRE, PAM, VEGA

IT projects at Saab EMPIRE, PAM, VEGA

GECU Saab-ESB

Part II: Supplier Networks

Sweden Product development process

Saab

Product development process Saab Collaborative product development of physical products IS/IT projects

(23)

unit, GECU). In the on-going New APESS project (half-way into the project during the time of this study), there was potential for introducing a web-based project management tool between the collaborating firms (via the PAM project). The previous development of the APESS system was just finished and could serve for comparison (of an “as-is”-“to-be” situation, as described for example in Profozich 1998). The previous APESS development served also as an example of relationship management for the product life cycle, when an outsourced product development project is finished. In order to be able to map the complete collaborative product development process, the third project, development of the GECU, was chosen, since it was just about to start at the time of the empirical study, and gave an opportunity to study the early phases with “make or buy” decision and selection of supplier. Altogether these cases were estimated to give a good view over the complete collaborative product development process, something that is further discussed in section 2.3 (Method for Analysis).

The IT track studied comprised development and implementation of IT (web-based) tools, the project management tool and others, for communication between the buyer-supplier parties in product development activities. These were complemented with extensive studies at IS/IT provider companies and benchmarking studies at similar companies (Boeing Military and Boeing Commercial). Moreover, research results were exchanged with a similar project conducted within the American LAI program (Antonelli 1999, see Kandebo 1997).

2.3.2 Case Selection Part II

The findings from Part I concerned dyad cases, where the product development activities carried out at the firms studied were not integrated but only coordinated. Moreover, a result from Part I was that the supplier had to manage a large number of subtiers. These results motivated me to conduct a complementary case study from the supplier perspective instead of the buyer perspective as in Part I. In Part II therefore, the population could be labeled: “product development carried out by a supplier network, studied from the supplier’s perspective”. Compared to the larger firms in Part I, the other polar type small business was studied here. The cases included different kinds of products and were conducted at various industries. Selection of cases was done from about thirty

(24)

identified Swedish supplier networks in the manufacturing industry, of which a handful carried out interfirm product development (to our knowledge). These were contacted, and the three most appropriate cases in terms of number of firms involved (more than two) and certain degree of product complexity (based on number of parts, technical fields, and the user interface, as defined by Clark and Fujimoto 1991) were chosen for the study. Due to our requirements for product complexity, a manufacturer and developer of wooden houses was not selected. Compared to the product complexity in Part I (multi-role combat aircraft, a high-tech and very complex product), though, the products studied in Part II were more traditional and based on established technology.

The IT track studied in Part II concerned development of a web-based communication platform for an SME network conducted in the form of action research studies. Studies of the IT infrastructure among the companies in the network were conducted, and a web-based standard solution was implemented in cooperation with an IS/IT company. The results of these studies are mentioned in Appendix C, and described in detail in Wennberg and Öhrwall Rönnbäck (2000).

2.3.3 Categorizing of Cases

In figure 2.3 the two parts are mapped according to their product complexity and interorganizational complexity (number of relationships to manage, eg Biemans 1995).

Figure 2.3 Positioning the selected cases in Part I and Part II according to their level of product complexity and interorganizational complexity.

Product complexity Interorganizational complexity PART II PART I Product complexity Interorganizational complexity PART II PART I Product complexity Interorganizational complexity PART II PART I

(25)

In order to further position the studied cases in a supply chain, figure 2.4 shows the firms in the cases studied schematically marked as parts of a supply chain. In the dyad situation in Part I, mainly the buyer and major supplier firms were studied, with the customer and subtiers only sketchily looked at. In the network situation in Part II all parties of the supply chain that contributed to the product development activities were studied.

Figure 2.4 Positioning the empirical cases of Part I and II in a supply chain view. (OEM stands for original equipment manufacturer.)

The major unit of study was both in Part I and in Part II product development projects. Nevertheless, the empirical studies were not limited to the projects, but included descriptions of the participating firm’s business situation and organization in connection to the product development activities studied (a holistic approach, as recommended by Melin 1989). To be able to work with such a holistic view is, as previously mentioned, one of the major advantages with case studies (Yin 1989).

The case studies have been conducted in several industries (aerospace and defense, construction, medico-technical), in various technical fields (mechanical engineering, electronics, and polymer industries), and different product complexity levels, with both high-tech products such as combat airplanes and more traditional product areas where the innovations involve mainly established technologies. The cases can be divided into three different types, as described in the discussion above:

1. Dyad studies of collaborative product development in the aerospace industry (Part I)

2. Studies of collaborative product development between a customer and several firms cooperating in supplier networks in

Second tier supplier Third - xth tier supplier OEM or first tier supplier Customer and end-user Systems integrator Part I:

Three cases of collaborative product development in the aerospace industry

Part II: Three cases of product development in supplier networks Second tier supplier Third - xth tier supplier OEM or first tier supplier Customer and end-user Systems integrator Part I:

Three cases of collaborative product development in the aerospace industry

Part II:

Three cases

of product development in supplier networks

(26)

respectively the mechanics, polymer and electronic industries (Part II)

3. Studies of IT tools and IT projects and in dyads and networks, connected to the dyad and supplier network cases studied (Part I and II)

2.3.4 Data Collection

Table 2.1 below gives further details, regarding when the cases were studied, when the events studied took place (which were in some cases studied in real time, but mainly in retrospect), the firms studied, and where the detailed case description can be found, and the research project of which it was part.

This latter, to take part of a larger project as a framework, had an impact both on data collection and on the analysis of the cases. To work in a group of several researchers can be a major advantage. According to Eisenhardt (1989), multiple investigators contribute with complementary insights and different perspectives, which may enhance both the richness of data collected and the likelihood of discovering new and interesting results. In both Part I and Part II of this research I took part in research teams where the researchers looked at the same empirical cases from various angles. Individual analysis was presented as tentative results within the research team, something that led to sharpened theoretical discussions as an important step of the analysis. This was a working method in both Part I (in the research project LARP) and Part II (in the research project NISAM). It is recommended as a strategy for several reasons; the enhanced confidence in the findings, where the researchers’ convergent or conflicting perceptions prevent the premature closing of the data collection of a case especially worth mentioning (Eisenhardt 1989).

(27)

Case Time period for the study

When the studied events

took place

Firms studied Case

description in Appendix

Research project

Collaborative product development cases

Saab product development

1997 Continuously Saab A ENDREA

PhD course APESS 328 1998-1999 1995-1999 Saab, Microturbo

(FMV)

A LARP New APESS 1998-1999 1997-1999 Saab, Sundstrand

Power Systems (FMV)

A LARP

GECU 1998-1999 1998-1999 Saab (Ericsson Radio

Systems)

A LARP Weapon lock 1999-2000 1998-2000 FMV-supplier network

with 5 firms and other organizations, VMU

B NISAM

Ventilation control system

1999-2000 1998-2000 ABB-supplier network with 5 firms, SLIT

B NISAM Platelet meter 1999-2000 1998-2000 Fält Elektronik –

supplier network of 10 firms, PUCK B NISAM IS/IT projects PAM, VEGA, EMPIRE

1998-1999 1998-1999 Saab, IS/IT providers A LARP

www.puck.se 1999-2001 1999-2001 PUCK and member firms, IS/IT providers

(B) IMIE

AWACS 1998 1997-1998 Boeing Military (A) LARP

Costran 1998-1999 1998-1999 Boeing Commercial,

IS/IT providers

(A) LARP Table 2.1 Overview of studied cases, time period, companies, and research

projects. The cases are described in detail Appendix A and B, except the IS/IT projects which are only briefly mentioned in these appendices.

The participation in the Lean Aircraft Research Program (LARP) set the empirical framework of Part I, with focus on the special conditions for the aircraft industry, especially the relationships between a systems integrator firm, its customer and major suppliers. Part I of this research lay within a sub-project with the objective "to make the integrated product development process in the buyer/supplier relation more effective in all phases through use of information technology, standardized data and integrated development tools".8

Part II was carried out mainly as a part of the national project NISAM9_{, initiated by a research institute to enhance knowledge} about industrial networks. Dealing specifically with product

8_{LARP was organized in subprojects, where this subproject was number 4, consisting of two}

parallel tracks; 4A - Use of model-based tools in the early phases, a study conducted by Göran Backlund, ENDREA (licentiate thesis 2000), and 4B - Web-based infrastructure in collaborative product development, which is this specific research. See

www.liu.se/org/imie/larp and NFFP report no 361 (Nationellt Flygforskningsprogram, the Swedish National Aerospace Research Program).

9_{The NISAM (Ny Industriell Samverkan) was sponsored by the Swedish National Board of}

(28)

development, this subproject10_{was one of about ten within the} research program.

Data collection was carried out in the form of interviews, meetings and on-site observations. In total approximately 60 interviews and meetings were carried out in 25 different companies during 1997-2000. These are listed for Part I in Appendix A and for Part II in Appendix B. Of the cases presented in table 2.1, the collaborative product development cases were studied in-depth. This means that several interviews and meetings were held with integrated product development team (IPT) members (mainly engineers from various disciplines, but also marketing and manufacturing professionals), product development managers and project managers, purchasing managers, and logistics managers. Especially in Part I also on-site observations were carried out at the focal firm. This was done only to limited extent in Part II of the study, mostly because of the large number of firms included in the study and the special characteristics of SMEs, whose activities often depend on one or only a few key persons. Interviews were carried out around the question areas presented in Appendix A (Appendices I and II) and Appendix E. All interviews and meetings were typed and summarized as soon as possible after they had been carried out (usually the same day). Most were also recorded and stored on tapes and CDs. A more thorough discussion about data collection in the in-depth case studies is given in Appendix A, section 3.2.4. The studied IS/IT projects presented in table 2.1 served more as a complement to the collaborative product development cases. Mainly the project managers and the software providers were interviewed. The exception lies in the PUCK case, where action research was carried out, including implementation of a web-based communication platform and about ten training occasions and seminars for the network member firms, as well as some hands-on training on site for some of them. Thus, the PUCK case can also be considered as an in-depth case study, although fewer formal interviews were carried out. However, since the web-based platform was implemented for use in the supplier network in general, and

10_{The objective of the subproject was: “To increase knowledge about how firms in company networks} can communicate and cooperate efficiently between each other and with a customer (systems integrator) throughout the product development process. From a company perspective, the goal is that this knowledge shall increase understanding for cooperation between individuals in distributed product development projects and the role of the customer in such project. An academic purpose is to spread generalized knowledge about new perspectives, new organizational forms, and new tools for distributed product development.”(Translated from the project plan in Swedish.)

(29)

not specifically for product development, it is considered as peripheral to this dissertation and not described in-depth here (see Wennberg and Öhrwall Rönnbäck 2000).

2.4 Method

for

Analysis

2.4.1 Within-Case and Cross-Case Analysis

The analysis carried out in this research is strongly empirically-based, and as such it is important that the researcher becomes closely familiar with each of the cases studied, as Eisenhardt expresses it:

the overall idea is to become familiar with each case as a stand-alone entity

(Eisenhardt 1989:540)

Within-case analysis was therefore carried out for each of the collaborative product development cases, as reported in the case descriptions in Appendix A (chapter 4) and in Appendix B (chapter 3). Writing down the case descriptions was done by an iterative procedure, alternating between data collection and within-case analysis. In parallel, cross-within-case analysis revealed any missing data in the cases, and if so, need to make complementary data collection before the cases were closed. The use of the same data collection instruments in the cases within Part I and within Part II respectively facilitated this cross-case analysis. Further, the iterative procedure of within-case analysis, cross-case analysis, and complementary data collection made it possible to describe the studied cases with the same categories for the cases that were studied for sampling purposes (two cases in Part I and three cases in Part II), as accounted for in table 2.2.

(30)

Part I Part II

The systems integrator The supplier Collaborative product development in

supplier networks - The product

- Integrated product development

(product development organization, development of complex system products, project organization, process descriptions and refinement of the process)

- Collaborative product

development, Formal information exchange and collocation (with

major suppliers)

- The IS/IT vision, current use of IT and development of future applications, restructuring the IS/IT function

- General about the project - Experiences from the project

at the supplier - Systems development - Information exchange - Current use of IT at the

supplier

- The supplier network studied - Local network - Product network - The collaborative product

development - Product development assignment - Buyer-supplier relationship - Supplier network relationship - Product characteristics - Risk and intellectual

property - Outcome - IT communication between the systems integrator and the supplier

Table 2.2 Descriptive categories for the studied cases of Part I (the systems integrator studied in-depth and the buyer-supplier dyads, see Appendix A) and Part II (collaborative product development in the three supplier networks, see Appendix B).

Moreover, this categorizing of the cases was an important analysis tool. Hopefully these categories also facilitate the reading of the cases.

In Part I the three collaborative product development cases were used to complement each other in the mapping of the collaborative product development process (shown in Appendix A, figure 3.3, which resulted in figure 5.5), a illustrated in figure 2.5. The three cases also served for theoretical sampling purposes, since three different firms were studied in order to increase understanding of integrated product development and management of IT for product development. These three were Saab and two of its major suppliers, Microturbo and Sundstrand Power Systems. The third supplier was not studied in-depth, since it as being selected during the course of the study.

(31)

Figure 2.5 The three cases of Part I (GECU, New APESS, and APESS) complemented each other for the mapping of the collaborative product development. (See Appendix A, figure 3.3 and 5.5.)

In the analysis of Part II the collaborative product development cases in the three supplier networks were used for theoretical sampling purposes. Part II was carried out in two steps of data collection, with thorough analysis carried out in between the phases, for example cross-case pattern analysis of the cases studied, ie setting various observed patterns against each other (for instance product modularity and distance between collaborating partners). The analysis after the first step revealed a need to complement data collection with the customer perspective. A new question guide was therefore developed (Appendix E). This working procedure when question guides are refined, and complementary cases are added successively as a result of ongoing within-case and cross-case analysis is common in case studies for theory building, according to Eisenhardt (1989).

Finally, the results of Part I were compared with those of Part II (in Appendix C). Thus, cross-case searching tactics were applied between Part I’s buyer perspective and dyad cases and Part II’s supplier perspective and network cases. Concerning analysis of “use of internet-based IT support for collaborative product development” the cases in the two parts served for theoretical sampling, of the population collaborative product development of physical products with polar cases: large firm – SME, dyad – network, close relationship – arm’s-length relationship (during development), integrated collaborative product development – GECU New APESS APESS 328 start: late 1997 start: early 1997 duration: 1994 -1998

(32)

coordinated collaborative product development, complex product – simple product (in several different industries and with modular or integral architecture).

2.4.2 Analysis Individually and in Research Teams

Analysis was carried out in research teams with researchers from different areas and with different theoretical backgrounds, where investigators who had carried out data collection on the field worked together with those who had not taken part in the interviews and meetings. Eisenhardt (1989) recommends this kind of cross-case analysis, since it can reveal new connections and patterns in the data (that the human mind hardly discovers due to our limitations as data processors!).

Within the LARP project, the results from the data collection were discussed at project meetings both internally in the research group, and externally together with representatives from industry (up to fifteen people in a conference room). These meetings were important for interpretation of the data. Besides these group meetings, before as well as after, the individual researchers in the team compared the empirical data with existing literature and previous studies. Preliminary results were often the basis for discussions. Thus, a pure grounded theory methodology (Strauss and Corbin 1990) was not applied during Part I. I agree here with criticism against the overconfidence in coding and disregard of the data’s dependence on theory, as presented by Alvesson and Sköldberg (2000).

In Part II a similar method for data analysis was applied. However, in this case the research team of about twenty researchers met less often, and the meetings with the industrial reference group had more the character of reporting meetings when the researchers presented their results, whose relevance and significance for industry were discussed. The analysis work took place mainly in smaller groups of researchers who worked together on subprojects. These smaller groups were often distributed (from different universities and research institutes) and therefore telephone conferences were common. Writing took place by individuals sharing the same document that was sent between the team members (and stored on a common web-based project platform). During meetings mainly the empirical data was analyzed. The theoretical background to the phenomena studied

(33)

was discussed when complementary interview guides were worked out, and when writing articles together (see Appendix D:[12], [13]). Besides the analysis in groups of researchers with contributions from reference groups from industry, most of the analysis was independent and individual work where I went through interview protocols, tapes and written material on several occasions both before and after having read other researchers’ earlier results. The interpretation of the results as I present it in this thesis is therefore my own, yet with influences from the above mentioned procedures.

2.4.3 Choice of Literature

The literature reviewed for this research has been a winding journey over a large number of theoretical fields, since previous research on collaborative product development derives from various underlying theoretical fields, eg business strategy and outsourcing literature (eg Sanchez 1995, Nischiguchi 1996, Quinn 2000), including strategic purchasing and interorganizational relationships (eg Gadde and Håkansson 1993, Lamming, Cousins, and Notman 1996), and engineering management (eg Allen 1977, Andreasen and Hein 1987, Pahl and Beitz 1996, Rechtin 1991), and also works based on the social science (Burns and Stalker 1962) and sociotechnical fields (Pava 1993) have come across. Moreover, the younger field of IT management has been explored, with authors such as Keen (1991) and Zuboff (1988), and especially the IOIS area (Fulk and DeSanctis 1995, Kumar and van Dissel 1996), which also is based on different theoretical areas. Both conflicting literature and literature supporting the emerging results and discussions have been used to develop the theoretical constructs.

2.5 Reflection on the Quality of the Research

Study

Measures taken in this research to enhance the quality of the study are, to summarize discussions in this chapter, 1) a listening attitude in interviews and meetings with respondents, and being careful not to influence the respondent with my own opinions or attitudes, 2) disregard of previous research and extant theories during field work (data collection), 3) constant iterations of data

(34)

collection and analysis, 4) feedback from respondents on field-notes, 5) research team evaluation of early constructs, 6) review of early constructs by reference groups with representatives from empirical case companies and projects, and 7) comparison between constructs and extant literature (both conflicting and agreeing).

Quality of this research can be discussed in terms of if the emergent theory generated from the case study has novelty value, is testable, and is empirically valid (internally and externally). Eisenhardt (1989) categorize these three measures as strengths of theory-building case studies. Weaknesses on the other hand mainly deal with the generalizability of the study. Eisenhardt mentions that the theory can be so rich in detail that it lacks the overall perspective, that the results are linked too much to the individual cases studied, and, in close connection to these, that they rarely lead to “grand theories” but rather to supporting some extant. Such aspects, which are recognized for this study, represent the risk with case studies attempting to be theory-generating and are taken into account in the following discussion.

Yin (1989) presents a useful framework for quality assertion for case studies, which will be used to describe measures taken for quality. In order to construct validity, multiple sources have been used for the empirical study (interviews, meetings, observations, internal company documents such as requirement specifications or product development software tools, etc), and key respondents have participated in reviews of documents and oral presentations of intermediary result. The tactics for internal validity has been to work with explanation building as an iterative process between individual analysis of data and discussions of constructs in the research teams. External validity was aimed at with three cases in Part I and the multiple case study in Part II. However, although a large number of interviews, company visits together with observations, and collection of secondary sources, the studied sample is small. This limitation to generalize is an inbuilt problem of in-depth case studies (Eisenhardt 1989).

As often recommended for case studies (Merriam 1994), I have tried to provide enough information on the cases studied, the data collection procedures, the analysis, and evidence for the constructs, in order for readers to make their own assessment of whether the resulting theory fits or not, and could be generalized from or not.

(35)

3 Frame of Reference

This chapter contains a brief summary of the theoretical framework for this research and definitions of key concepts used in the thesis. More ample theoretical background is presented in the three appendices A-C.

3.1 Definition and Discussion of Key Concepts

Collaborative product development includes always a business relationship between the parties, which makes it different from in-house product development. In general, the buyer-supplier relationship is changing and the interaction between cooperating companies is growing increasingly complex, as some authors claim is due to the possible interconnectivity with information systems and the internet (Bettis and Hitt 1995, Chandrashekar and Schary 1999, Lambert and Cooper 2000).

Concerning business relationships in general, Gummesson (1995) speaks of the many-headed customer and the many-headed supplier. There is no longer one-to-one communication between cooperating companies. Instead, individual contacts have shifted towards multiple team contacts at several levels simultaneously. Moreover, there is a need to assess the relationship instead of one-sidedly evaluate the supplier (Lamming, Cousins, Notman 1996), and find a strategic management approach to how firms can gain a sustainable position within a supply and value chain (Cox 1996). Several authors call for a more dynamic view of how the firm shall manage its network relationships in supply and value chains (Miles and Snow 1994, Ciborra 1996), since business relationships of this kind can involve everyone in the firm, not only the purchasing department. Reciprocally, with more supplier contacts in several business processes, purchasing has an important strategic function in eg product development (Wynstra 1998). Questioning existing theoretical organization models, Ciborra

(36)

(1996) suggests for example the platform organisation as a new concept for firms to obtain the flexibility and dynamism needed to manage technological discontinuities and changing organizational borders.

Some clarifications of key concepts for this work are required. To start with, the terms collaboration and cooperation will be used synonymously in this work. Collaboration has become the generally accepted term used both in theory and in practice to denote business cooperation when two or more companies join their efforts to reach common goals, for example in collaborative commerce (c-commerce) or in collaborative product development (CPD).

Further on, in this work, coordination of collaborative product development refers to mapping activities against each other and to see to that input and output is delivered when needed (in the general meaning for organizing business activities, as eg in Mintzberg 1983).

Third, the difference between coordination and integration is central. Integration refers to the IPD concept, ie that cross-functional integration is required for more efficient and effective product development. Andreasen and Hein (1987) present the product development process as a three-folded process of parallel activities in marketing, manufacturing and traditional R&D activities. IPD has given birth to the expression integrated product development team, abbreviated as IPT, commonly used in the American literature and firms to denote the multifunctional team that works with a product development assignment (eg Fine 1998). An IPT consists in general of representatives from marketing, manufacturing and the technical areas needed for the development. Integration in product development is a means to coordinate closely linked activities and functions in the product development process.

IPD in collaborative (interfirm) development is needed when a necessary functional area lies outside the firm. According to Ragatz et al (1997), to integrate suppliers in the new product development work depends on the firm’s willingness to share assets, including (1) intellectual assets, such as customer requirements, technology information, and cross-functional communication, (2) physical assets, such as linked information systems, technology, plant and equipment, and (3) human assets,

(37)

such as project team participation. Lambert and Cooper (2000), with a similar definition of integration in supply chain business processes, question how many suppliers that a buying firm actually can manage to work together with in an integrated manner. They illustrate this from a supply chain management perspective with figure 3.1, referring to this as cross-functional business process integration “penetrating functional silos within the company” (p 66), where product development is one of a number of processes, as illustrated in figure 3.1. The authors also show that information flow between the parties is one of the main challenges in order to obtain an efficient supply (or value11_{) chain.} A supply chain management perspective on product development does not stand in conflict with the criticism against the supply chain view on product development presented by Clark and Fujimoto (1991). Their argument that the traditional view of flow of materials from supplier to manufacturer to marketer and out to the customer should be revisited and changed into a flow of information instead, from product concept that takes input from the customer, is thus coherent with the previous discussion of product development work as an iterative process, rather than a straight-forward chain. Supply chain in this context refers to the different parties involved, from the end-user and customer (which can be separate entities) to the systems integrator, major suppliers and subtiers of different orders (first, second, etc), and is the established terminology in the logistics and purchasing literature (Christopher 1994, Cox 1996, Wynstra 1998).

11_{Value chain and supply chain (and value net, see Nalebuff and Brandenburger 1996) are used}