oulu 2012 actajultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be...

124
UNIVERSITATIS OULUENSIS ACTA C TECHNICA OULU 2012 C 440 Anyanitha Distanont KNOWLEDGE TRANSFER IN REQUIREMENTS ENGINEERING IN COLLABORATIVE PRODUCT DEVELOPMENT UNIVERSITY OF OULU GRADUATE SCHOOL; UNIVERSITY OF OULU, FACULTY OF TECHNOLOGY, DEPARTMENT OF INDUSTRIAL ENGINEERING AND MANAGEMENT C 440 ACTA Anyanitha Distanont

Upload: others

Post on 05-Jul-2020

0 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

ABCDEFG

UNIVERS ITY OF OULU P.O.B . 7500 F I -90014 UNIVERS ITY OF OULU F INLAND

A C T A U N I V E R S I T A T I S O U L U E N S I S

S E R I E S E D I T O R S

SCIENTIAE RERUM NATURALIUM

HUMANIORA

TECHNICA

MEDICA

SCIENTIAE RERUM SOCIALIUM

SCRIPTA ACADEMICA

OECONOMICA

EDITOR IN CHIEF

PUBLICATIONS EDITOR

Senior Assistant Jorma Arhippainen

University Lecturer Santeri Palviainen

Professor Hannu Heusala

Professor Olli Vuolteenaho

University Lecturer Hannu Heikkinen

Director Sinikka Eskelinen

Professor Jari Juga

Professor Olli Vuolteenaho

Publications Editor Kirsti Nurkkala

ISBN 978-952-62-0053-8 (Paperback)ISBN 978-952-62-0054-5 (PDF)ISSN 0355-3213 (Print)ISSN 1796-2226 (Online)

U N I V E R S I TAT I S O U L U E N S I SACTAC

TECHNICA

U N I V E R S I TAT I S O U L U E N S I SACTAC

TECHNICA

OULU 2012

C 440

Anyanitha Distanont

KNOWLEDGE TRANSFERIN REQUIREMENTS ENGINEERINGIN COLLABORATIVE PRODUCT DEVELOPMENT

UNIVERSITY OF OULU GRADUATE SCHOOL;UNIVERSITY OF OULU,FACULTY OF TECHNOLOGY,DEPARTMENT OF INDUSTRIAL ENGINEERING AND MANAGEMENT

C 440

ACTA

Anyanitha D

istanont

C440etukansi.kesken.fm Page 1 Wednesday, December 12, 2012 1:20 PM

Page 2: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää
Page 3: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

A C T A U N I V E R S I T A T I S O U L U E N S I SC Te c h n i c a 4 4 0

ANYANITHA DISTANONT

KNOWLEDGE TRANSFER IN REQUIREMENTS ENGINEERINGIN COLLABORATIVE PRODUCT DEVELOPMENT

Academic dissertation to be presented, with the assent ofthe Doctoral Training Committee of Technology andNatural Sciences of the University of Oulu, for publicdefence in Wetteri-sali (IT115), Linnanmaa, on 17 January2013, at 12 noon

UNIVERSITY OF OULU, OULU 2012

Page 4: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Copyright © 2012Acta Univ. Oul. C 440, 2012

Supervised byProfessor Harri Haapasalo

Reviewed byDoctor Jussi AutereDoctor Pekka Berg

ISBN 978-952-62-0053-8 (Paperback)ISBN 978-952-62-0054-5 (PDF)

ISSN 0355-3213 (Printed)ISSN 1796-2226 (Online)

Cover DesignRaimo Ahonen

JUVENES PRINTTAMPERE 2012

Page 5: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Distanont, Anyanitha, Knowledge transfer in requirements engineering incollaborative product development. University of Oulu Graduate School; University of Oulu, Faculty of Technology, Department ofIndustrial Engineering and Management, P.O. Box 4610, FI-90014 University of Oulu, FinlandActa Univ. Oul. C 440, 2012Oulu, Finland

Abstract

At present, collaborative strategies are an important part of developing the capabilities to be ableto compete in the 21st Century since knowledge or innovations cannot develop entirely within asingle firm. Collaboration provides invaluable resources that a firm cannot create throughknowledge transfer mechanisms. The purpose of this doctoral dissertation is to enhanceunderstanding of knowledge transfer in requirements engineering in the context of collaborativeproduct development. The research is qualitative by nature and utilises the case studymethodology. Data collection was conducted through interviews and surveys with informants inhigh-tech enterprises. The results indicate that collaboration in product development is veryimportant and acts as a means of obtaining external resources, especially knowledge. However,collaboration is not an easy practice; it involves many challenges. In order to improve the practiceof collaboration, it is necessary to manage and leverage the transfer of knowledge. According tothe results, in order to increase the effectiveness of knowledge transfer over enterprise interfaces,each knowledge type needs to be transferred through the suitable transfer channel at the right time.The results also indicate that the individual relationships among buyers and suppliers are anessential element for long-term collaboration and common platforms or tools need to be developedto support collaborative product development over enterprise interfaces.

Keywords: collaboration, collaborative product development, high-tech enterprise,knowledge transfer, requirements engineering, social network

Page 6: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää
Page 7: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Distanont, Anyanitha, Osaamisen siirto tuotekehitysyhteistyön vaatimustenhallinnassa. Oulun yliopiston tutkijakoulu; Oulun yliopisto, Teknillinen tiedekunta, Tuotantotalouden osasto,PL 4610, 90014 Oulun yliopistoActa Univ. Oul. C 440, 2012Oulu

Tiivistelmä

Kiristyvän kilpailun tilanteessa yritykset etsivät keinoja tehostaakseen toimintaansa. Yksi keinotähän on yhteistyökumppanina toimivien yritysten hyödyntäminen tuotekehityksessä. Yhteistyö-kumppanien hyödyntämisellä yritykset pyrkivät muun muassa tukemaan innovatiivisuutta ja täy-dentämään tuotekehityksessä tarvittavia kyvykkyyksiä. Tähän pyritään hankkimalla lisää resurs-seja, erityisesti tietämystä ja osaamista, jota yrityksellä ei itsellään ole tai joka on ulkoistettuaiemmin. Tässä väitöskirjassa perehdytään yritysyhteistyötä hyödyntävään tuotekehitystoimin-taan ja tutkimuksen tavoitteena on lisätä ymmärrystä osaamisen siirrosta erityisesti vaatimustenhallinnan prosessissa.

Tämä väitöskirjatyö on laadullinen tapaustutkimus. Tutkimuksen empiirinen aineisto on han-kittu haastatteluilla ja kyselyillä korkeanteknologian yrityksistä. Tutkimustulosten mukaan yri-tysten välinen yhteistyö tuotekehityksessä on merkittävässä roolissa moderneissa yrityksissä.Tällöin voidaan puhua ulkopuolisten resurssien, erityisesti ulkoisen osaamisen hyödyntämisestätuotekehityksessä.

Tulosten mukaan on kuitenkin huomioitava, että yritysyhteistyö on varsin monimutkaista jahaastavaa toteuttaa. Yritysten tulee paremmin johtaa osaamisen siirtoa yhteistyökumppaneidenvälillä ja panostaa osaamisen siirtoon liittyviin toimintatapoihin ja työkaluihin. Yritysten väli-sen osaamisen siirron tehokkuuden lisäämiseksi tulee huomioida, että erityyppinen osaaminentulee siirtää sille ominaisen kanavan kautta juuri oikeaan aikaan. Tulosten mukaan yrityksissätoimivien henkilöiden väliset suhteet ovat keskeisessä roolissa pitkän aikavälin yritysyhteistyöl-le. Tukeakseen paremmin yritysyhteistyötä tuotekehityksessä yritysten tulisi kehittää yhteisiäalustoja tai työkaluja osaamisen siirtoon.

Asiasanat: korkeanteknologian yritys, osaamisen siirto, sosiaaliset verkostot,vaatimustenhallinta, yritysyhteistyö, yritysyhteistyö tuotekehityksessä

Page 8: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää
Page 9: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

7

Acknowledgements

In the spring of 2009, I learned how to survive in one of the coldest countries

alone. It was a very tough time but it also became a lovely time for me as I

walked to the Department of Industrial Engineering and Management (DIEM) at

the University of Oulu as a PhD student. My long journey had started and I could

not have reached my destination without the guidance and support of several

people around me who contributed and dedicated their valuable time and

assistance to helping me complete this journey.

I would first like to express my deep and sincere gratitude to my supervisor,

Professor Harri Haapasalo, for the support and guidance he showed me

throughout my studies. His knowledge and logical way of thinking have been a

great inspiration for me. I am sure this thesis would not have been possible

without his help. His sincerity and encouragement I will never forget. I appreciate

very much all he has done to support me. Professor Harri, you are the best. I

could only hope be as lively, enthusiastic and energetic as he is.

I am truly indebted and thankful to the Head of DIEM, Professor Pekka Kess,

who offered me the invaluable opportunity to study at DIEM. Professor Pekka,

the opportunity you have given me has not only broadened my education and

professional experience, but it has also been a life-changing experience for me.

You also always supported me and helped me when I had many questions about

doing research or even other questions or problems I have faced while living in

Finland. He is truly an inspiration for me. I feel so happy and blessed for the

opportunity to work with him. I cannot thank you enough for everything he did

for me over the past 3 years. I owe a lot of my success to him.

I also want to thank Dr Mirja Väänänen for providing many suggestions and

careful reviews. Her positive comments, suggestions and criticisms along the way

have been very helpful for this study, and have kept up my motivation. I also

would like to thank Dr Hanna Kropsu-Vehkaperä, for not only providing many

suggestions and relevant information for this research but also for giving the

structure review of this dissertation. Thank you Mirja and Hanna, you have also

provided assistance and encouragement that made this research easier and more

enjoyable.

I would like to show my gratitude to Associate Professor Bordin

Rassameethes, Dean of the Faculty of Business Administration at Kasetsart

University in Thailand for his important support. You have given me not only

academic knowledge but also real life experience. Thank you, A Bordin, for

Page 10: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

8

believing in me, and for teaching me with patience and understanding. My sincere

thanks are also extended to Assistant Professor Kongkiti Phusavat, Dr Suparerk

Suksamarn, Assistant Professor Anan Mungwattana, Head of Department of

Industrial Engineering at Kasetsart University in Thailand and Assistant Professor

Tavida Kamolvej, Associate Dean for Academic Affairs at the Faculty of Political

Science at Thammasat University in Thailand. Thank you, A Kongkiti and

A Suparerk for always giving me valuable advice and strong support. Thank you,

A Anan for helping me to contact companies to make interviews. Thank you,

A Tavida, for your valuable advice and friendly help. Your guidance and extensive

discussions about social network analysis has been of great value in this study.

Sincere thanks are also due to Professor Harri Haapasalo, Professor Pekka

Kess, Associate Professor Bordin Rassameethes, Dr Binshan Lin, Dr Tavida

Kamolvej, Dr Sasivimol Meeampol, Dr Mirja Väänänen, Dr Hanna Kropsu-

Vehkaperä, Mr Jari Lehto and Ms Suvi Marja Tuulia Siira, all of whom have been

my co-authors in conference papers or journal articles. Their detailed reviews,

valuable support and contributions to the articles have been extremely helpful for

this research.

Special thanks also go to the companies and the company representatives

taking part in this research, especially Mr Jari Lehto, Ms Maarit Makkonen,

Mr Heikki Makarainen, Mr Watcharathorn Pongsri and Mr Thawatchai

Thaworasak, for providing their time and professional knowledge. They have

offered me a great learning opportunity for collaborative work and a great deal of

knowledge transfer in practice.

I wish to thank Dr Pekka Belt, Dr Janne Härkönen and Dr Matti Möttönen,

for giving me guidance of writing the thesis and providing me with very useful

suggestions about the way of doing research.

I also wish to thank my former and present colleagues at DIEM for your co-

operation and friendly help. Special thanks are due to Dr Mirja Väänänen,

Dr Hanna Kropsu-Vehkaperä, Dr Matti Muhos, Mr Tuomo Kinnunen and Mr Aki

Aapaoja for your valuable support, your kindness and your friendship. I will

never forget.

My sincere thanks are due to the pre-examiners Dr Jussi Autere and Dr Pekka

Berg for their constructive critique of the thesis.

I would like to show my gratitude to the following foundations that gave me

financial support during my doctoral studies and thesis work: The Finnish

Doctoral Program in Industrial Engineering and Management, The Finnish

Page 11: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

9

Cultural Foundation, Riitta ja Jorma J. Takanen Säätiö, Tekniikan

edistämissäätiön (TES) and Tauno Tönningin Säätiö.

Additionally, the most important thing that has helped me achieve my goal is

my family. Without their support, inspiration and encouragement, I couldn’t have

been this and I could not have made it this far. To my sister, P Gaew, thank you

for always supporting me, believing in me and always being there for me

whenever I needed. To my brother-in-law, P Pom and my sisters, P Au and Lek,

thank you for your continued support, belief in me and understanding. You always

stand beside me and you are always ready to support me unconditionally. I love

you all with all of my heart. Last but not the least, to my Mom and Dad, thank

you for always supporting me in every possible way, believing in me, being proud

of me, inspiring me, loving me unconditionally and encouraging me to succeed.

You helped me reach my full potential and become who I am today. I couldn’t

have done it without you. I promise I will always strive for the best. I love you

with all my heart.

Oulu, Finland, December 2012 Anyanitha Distanont

Page 12: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

10

Page 13: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

11

List of abbreviations

CPD Collaborative product development

KT Knowledge transfer

RE Requirements engineering

SN Social network

SNA Social network analysis

D Data

I Information

K Knowledge

Page 14: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

12

Page 15: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

13

List of original publications

This dissertation is based on the following publications:

I Distanont A, Haapasalo H, Rassameethes B & Lin B (2011) Developing new product through collaboration in high-tech enterprises. International Journal of Management and Enterprise Development 10(1): 51–71.

II Distanont A, Haapasalo H, Rassameethes B & Lin B (2012) Knowledge transfer pattern in collaborative product development. International Journal of Intercultural Information Management 3(1): 59–81.

III Distanont A, Haapasalo H, Kamolvej T & Meeampol S (in press) Interaction patterns in collaborative product development (CPD). International Journal of Synergy and Research.

IV Distanont A, Haapasalo H, Vaananen M & Lehto J (in press) The engagement between knowledge transfer and requirements engineering. International Journal of Management, Knowledge and Learning.

V Distanont A, Haapasalo H & Vaananen M (in press) Organising knowledge transfer in requirements engineering over organisational interfaces. International Journal of Innovation and Learning.

The author of this dissertation is the primary author of all original publications.

The researcher has been responsible for the entire research process, from

formulating research problems, collecting the theoretical base, formulating the

research questions, coordinating the collection of empirical material, analysing

the material and drawing conclusions. The role of co-authors includes reviewing

and commenting the article manuscripts of the first author.

Page 16: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

14

Page 17: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

15

Contents

Abstract

Tiivistelmä

Acknowledgements 7 List of abbreviations 11 List of original publications 13 Contents 15 1 Introduction 17

1.1 Background and research environment ................................................... 17 1.2 Objectives and scope ............................................................................... 20 1.3 Research process and dissertation structure ............................................ 23 1.4 Key concepts ........................................................................................... 27

2 Theoretical foundation 29 2.1 Theoretical framework ............................................................................ 29 2.2 Collaborative product development (CPD) ............................................. 31

2.2.1 Nature of product development .................................................... 32 2.2.2 The concept of collaborative product development ...................... 38 2.2.3 Buyer-supplier relationships ......................................................... 40 2.2.4 Supplier collaboration in collaborative product

development ................................................................................. 41 2.2.5 Front-end of innovation process ................................................... 44

2.3 Knowledge transfer (KT) ........................................................................ 46 2.3.1 Data, information, knowledge ...................................................... 46 2.3.2 Types of knowledge ...................................................................... 48 2.3.3 The knowledge transfer process ................................................... 51 2.3.4 Factors influencing knowledge transfer ....................................... 55

2.4 Social network (SN) theory ..................................................................... 57 2.4.1 The social network analysis (SNA) concept ................................. 57 2.4.2 Types of individuals in the network ............................................. 59

2.5 Requirements engineering (RE) .............................................................. 60 2.5.1 The requirements engineering process ......................................... 60 2.5.2 Requirements ................................................................................ 65

2.6 Theoretical synthesis ............................................................................... 70 3 Research contribution 73

3.1 Challenges of CPD .................................................................................. 73 3.2 Knowledge transfer pattern in CPD ........................................................ 76

Page 18: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

16

3.3 Individual interaction pattern in CPD ..................................................... 79 3.4 Challenges of KT in the RE process ....................................................... 81 3.5 Organising KT in the RE process ............................................................ 82 3.6 Results synthesis ..................................................................................... 84

4 Discussion 89 4.1 Theoretical implications .......................................................................... 89 4.2 Practical implications .............................................................................. 92 4.3 Reliability and validity ............................................................................ 94 4.4 Recommendations for further research ................................................... 98

References 101 Original publications 119

Page 19: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

17

1 Introduction

1.1 Background and research environment

The environment in which companies must operate today is structurally much

more complex than that which existed several years ago. This is due to the

following closely related trends: globalisation, the complexity of product

development, the changing supply chain lifecycle structure and the extent to

which it has become fragmented (Horney et al. 2010). The ongoing globalisation

– the increasingly intensified competition, the nature and dynamics of change, the

chaos and confusion that surround a company, the uncertainty of technology and

resource scarcity (Horney et al. 2010; Cetinkaya 2011) create many challenges

and increase the difficulty of developing a new product. Regarding product

development, new products are a key element for a company to possess a

competitive advantage (Cooper 2011), especially for products in the high-tech

industry. High-tech products can create new markets, accelerate growth and also

provide companies with opportunities to distinguish their products (McGrath

2000). However, developing a high-tech product is not an easy task and it

involves many challenges: continuous and rapid changes in technology, the

complexity of technology and faster product commoditisation/shorter lifecycle.

The high-tech product also requires various fields of knowledge, skills and

expertise. It is not sufficient to rely on sources within the company alone. These

challenges make product development in high-tech companies much more

difficult than products in other industries (Chakrabarti 2003; McGrath 2000).

Thus, the new generation of products also create a somewhat difficult product

development situation in the high-tech industry.

With these global phenomena, companies need to find a way to manage and

reduce any difficulties with product development by shifting away from a one-

dimensional supply chain to a fragmented supply chain (Anderson & Holmes

1995; Ferry 2004; Horney et al. 2010). In addition to the fragmented supply chain,

companies need to fragment product development. Moreover, due to the increased

globalisation of markets, in the 1990s high-tech companies were driven to decide

to concentrate on their competencies and outsource the non-core operations from

the internal production to external entities that specialise in the operations

(Horney et al. 2010; Hussinger 2005). However, currently when the companies

are developing new products they do not have any more supporting competencies

Page 20: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

18

in-house. Thus, companies need to collaborate in product development.

Collaborative product development is of crucial importance to establish business

relationships with other companies in order to engage in activities and gain access

to resources outside their own boundaries, particularly knowledge, which are

necessary for the development of a new product (Grant & Barden-Fuller 2004).

Thus, due to such trends and the current phenomenon, collaborative product

development is required and has become an important strategy for developing

products in high-tech companies nowadays.

Knowledge transfer is one of the crucial elements in collaborative product

development (Inkpen & Pien 2006; Yang & Kim 2007). It is one important

approach to access and obtain new knowledge, new skills or new resources that

the company cannot develop or reasonably produce internally. Efficient product

development requires efficient knowledge transfer throughout the collaborative

product development process. By collaborating, firms are able to transfer both

explicit and tacit knowledge in order to utilise different knowledge, skills and

experiences from their partner’s capabilities (Lang 2004). The high level of

interaction among collaborators encourages the knowledge transfer, especially

tacit knowledge that coincides with the high degree of trust that accompanies

collaborative relationships (Lang 2004). Transferring knowledge could be

achieved when the knowledge possessed by each party is transferred to another

person for the development and the creation of the new products (George et al.

2001). An organisation that is better able to transfer knowledge seems to be more

successful in developing the products. Regarding high-tech companies,

cooperation in developing products can affect the improvement and development

of the organisation’s potential and the organisation can increase its capability by

integrating a wide range of knowledge and skills developed by partners (Ding

2011). Therefore, the success of collaborative product development often hinges

on ensuring that people are collaborating effectively in knowledge transfer (Grant

& Barden-Fuller 2004).

Companies can also seek many potential benefits from collaboration in

product development including faster product development, reduced development

cost, reduced risk and increased access to the knowledge and development

capabilities of the firm’s partners, which can lead to a higher learning process

(Bruce et al. 1995; Daniel et al. 2002; Lau et al. 2010). In addition to the

advantage offered by collaborative product development, there are many

challenges that affect a successful collaboration (Littler et al. 1995), especially in

the early development lifecycle phase – the requirements engineering process (RE)

Page 21: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

19

(Nair 2009; Raatikainen et al. 2011; Sommerville 2006; Wiegers 2003). RE is

pivotal for effective product development, since requirements act as a map

guiding workers on how to work in each coming stage of product development

until the project is finalised. Without a good map, it is difficult to reach the

destination successfully. To develop requirements, these people need to

communicate and transfer knowledge about the requirements to achieve a

common understanding of stakeholders’ needs and requests (Zahay et al. 2004).

However, transferring requirements during product development is challenging,

especially when a company uses suppliers and the requirements need to be

transferred across company boundaries. This is especially challenging because the

requirements themselves are not always directly tangible and knowledge about

them is mostly tacit (Goffin et al. 2010). Additionally, the number of people

involved and the complexity of the products affects the importance of efficient

knowledge flow.

Numerous theoretical and conceptual frameworks of knowledge transfer itself

have been proposed. Some of them concentrated on studying models or processes

of knowledge transfer within or between organisations (e.g. Albino et al. 1999;

Argote & Ingram 2000; Gilbert & Cordey-Hayes 1996; Gupta & Govindarajan

2000; Inkpen & Dinur 1998; Nonaka & Takeuchi 1995; Sverlinger 2000), some of

them emphasised facilitating factors of knowledge transfer (e.g. O’Dell &

Grayson 1999; Li 2004), and there is also a massive literature involving the study

of influential factors of knowledge transfer (e.g. Al-Salti & Hackney 2011;

Arntzen-Bechina & Leguy 2007; Cohen & Levinthal 1989; Giannakis 2008;

Hansen 1999; Levin & Cross 2004; Libing & Rong 2007; Szulanski 2000; Wang

et al. 2004). Furthermore, some studies have stated that management of

knowledge transfer between partners ensures the success of collaborative product

development (Seppälä 2001; Squicciarini & Loikkanen 2008; Yang & Kim 2007).

Currently, although many studies of knowledge transfer have been conducted,

few specifically explore the issue of knowledge transfer in collaboration practices,

especially in the early lifecycle phases known as the requirements engineering

process (Pilat & Kaindl 2011). Therefore, this dissertation is an effort to bridge

this gap by focusing on requirements engineering process in the context of

collaborative product development as a platform to study knowledge transfer.

Page 22: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

20

1.2 Objectives and scope

This dissertation discusses knowledge transfer in requirements engineering over

enterprise interfaces in high-tech companies. The collaboration over enterprise

interfaces involves an effective knowledge transfer and one way to ensure success

in collaborative development is to examine the way knowledge transfers between

two parties while they are involved in developing a product. The overall objective

of this dissertation is as follows:

To enhance understanding of knowledge transfer in requirements engineering

in the context of collaborative product development.

In order to meet the objective of this dissertation, the following research

questions are formed (Table 1):

Table 1. Research questions.

RQ# Research question

RQ1 What are the challenges of collaborative product development in high-tech companies?

RQ2 What is the pattern of knowledge transfer in collaborative product development?

RQ3 How are individuals interacting in collaborative product development?

RQ4 What are the challenges of knowledge transfer practices in the requirements engineering

process?

RQ5 How can knowledge transfer in the requirements engineering process be improved?

These research questions are formed for compiling the research findings as a

whole. They are formed from five complementary perspectives – challenges of

CPD (Article 1), knowledge transfer patterns in CPD (Article 2), interaction

patterns in CPD (Article 3), challenges of knowledge transfer in the RE process

(Article 4), and means to overcome the challenges of knowledge transfer in the

RE process (Article 5). These research questions are related to each other, even

though their focus is different. The research questions from one to five move from

a wider to a more narrow subject matter.

The research focuses on requirements engineering in a practical context to

study knowledge transfer over organisational interfaces. The unit of analysis of

this research is a development project.

This study addresses the research questions in a qualitative approach both

through literature study and empirical research. Each research question is

answered with a journal article. RQ1, 2, 3, 4 and 5 are answered by Articles I, II,

III, IV and V respectively (see Table 2).

Page 23: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

21

Table 2. Research paper overview.

Article RQ# Article title Journal

I RQ1 Developing new product through collaboration in

high-tech enterprises

International Journal of

Management and Enterprise

Development

II RQ2 Knowledge transfer pattern in collaborative

product development

International Journal of Intercultural

Information Management

III RQ3 Interaction patterns in collaborative product

development (CPD)

International Journal of Synergy

and Research

IV RQ4 The engagement between knowledge transfer

and requirements engineering

International Journal of

Management, Knowledge and

Learning

V RQ5 Organising knowledge transfer in requirements

engineering over organisational interfaces

International Journal of Innovation

and Learning

Figure 1 illustrates the positioning of the five research questions within the

collaborative product development (CPD) context. The first and second articles

study collaborative practices and knowledge transfer practices, respectively at the

overall level. The first paper studies collaboration practices over enterprise

interfaces in order to understand and clarify the challenges of collaborative

product development. The second article studies the knowledge transfer pattern

across boundaries during collaborative work. This article discusses knowledge

transfer in order to understand the pattern of successful knowledge transfer in

CPD. The third paper studies knowledge transfer at the social level. It studies the

relationships among human resources while transferring knowledge in CPD in

order to gain a better understanding of the interaction pattern that can indicate a

problem or impediment to the improvement of knowledge transfer. The fourth and

fifth articles go deeper into the early lifecycle – into the requirements engineering

process. The fourth article clarifies the challenges of transfer practices in the

requirements engineering process. The fifth paper focuses on improving the

transfer practices in requirements engineering by investigating the means to

overcome the knowledge transfer challenges.

Page 24: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

22

Fig. 1. Research framework.

This dissertation studies knowledge transfer between buyers and suppliers in

high-tech companies. The focus of this dissertation is scoped on the collaboration

where suppliers work for buyer processes and supply or deliver some kind of

entities (either tangible or intangible) to buyers and both suppliers and buyers

have their own processes.

The main characteristic of high-tech companies is that they are knowledge-

based learning enterprises (OCED 2003). The Organisation for Economic Co-

operation and Development (OCED) defined high-tech industry as broadly

covering enterprises that are knowledge-intensive and technology-intensive.

Industries identified as high-tech are aerospace, pharmaceuticals, computers and

office machinery, electronics and communication equipment, and scientific

instruments. High-tech is an abbreviation of high-technology and it is also

referred to as hi-tech. It is defined as being involved in or making use of highly

advanced technological development or devices. In this dissertation, a high-tech

company is defined based on OCED’s classification. The study is particularly

scoped in consumer electronics, telecommunications, software and semiconductor

companies and their products combine hardware, software and service.

Page 25: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

23

1.3 Research process and dissertation structure

The way in which researchers collect data to answer their research questions may

be conceived of as the research philosophy, research approach, research strategy

and data collection methods.

Research philosophy

A research philosophy is a belief about the way in which data about a

phenomenon should be gathered, analysed and used. According to Bryman and

Bell (2007), the research philosophy can be approached through the concepts of

epistemology and ontology. On the one hand, the term epistemology is the

knowledge of/about knowledge (Johnson & Duberley 2000) and it is concerned

with the study of the nature and extent of knowledge and truth. Epistemology can

be roughly divided into positivism and interpretivism (Saunders et al. 2007).

Positivism is based upon the natural sciences and seeks to explain and predict

what happens in the social world. Interpretivism is relativistic and highly

dependent on the individual viewpoint (Saunders et al. 2007). Ontology, on the

other hand, is concerned with the nature of being, reality and existence – whether

the reality is objective in itself or a product of an individual’s mind. Ontology

influences the choice of theory and concepts, which are divided into objectivism

and subjectivism. Objectivism refers to the act of being objective or accurate and

bias-free, which implies that something exists in and of itself and is not

influenced by the researcher or the measurement instruments. On the other hand,

subjectivism involves the interpretation of a person’s internal reality rather than

pure external and independent facts (Bryman & Bell 2007).

In this research, the study is positioned closer to subjectivism and

interpretivism. Interpretivism is based on the assumption that research

participants respond in a subjective way (Saunders et al. 2007). Interpretivism

draws meaning through the interpretation of events and attempts to understand the

subjective reality of those that they study in order to make sense and understand

their motives, actions and intentions.

Research approach

There are two main research approaches: the deductive approach and the

inductive approach. The deductive approach (theory testing) develops a theory

Page 26: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

24

and hypothesis and designs a strategy to test the hypothesis. Another approach is

the inductive approach (building theory). In this approach, the researcher collects

data and develops a theory as a result of data analysis. The deductive approach is

typically a quantitative approach and is used when it is possible to specify

variables that can be measured or tested as numbers. The inductive approach is

typically a qualitative approach involving the use of qualitative data to provide an

in-depth understanding of the studied phenomenon (Bryman & Bell 2007).

Qualitative research focuses on seeing and learning the world from the viewpoint

of the people working in organisations and doing particular jobs (Hannabuss

1996).

In this research, the inductive or qualitative approach is used. The aim of

qualitative research is to understand the phenomenon being studied. The

qualitative approach enables the researcher to study the phenomenon in detail

(Irvine & Gaffikin 2006).

Research strategy

There are a large number of research strategies. Galliers (1991) identified 14

research methodologies including, for example, field experiment, survey design,

case study design, simulation, future research and forecasting.

In this research, the case study strategy was chosen. Case study research is

particularly appropriate for research that deals with practice-based problems

where the experiences of the respondents are important. It realises the true

environment and aims to study the phenomenon in depth (Yin 2009). This

research started studying knowledge transfer from the general level with multiple

case studies and then moved to the specific area of a single case study in the

context of collaborative product development. The first three research questions

are studied in order to gain an overall understanding of the collaborative product

development practices and knowledge transfer practices. These studies were

conducted in several high-tech companies. The other two research questions are

studied on the basis of a single case company. A single case study is appropriate

when the case studied is special to understand and clarify (Voss et al. 2002).

These studies utilise a single case in order to understand knowledge transfer in a

specific area – the requirements engineering process in the context of

collaborative product development. However, the criteria or the reasoning for

selecting the case companies and informants is the same in every study. All of the

case companies and the informants were selected based on Yin’s (2009) criteria of

Page 27: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

25

validating case studies and informants. Therefore, the case companies and the

informants were carefully selected on the basis of their professional background

and expertise. The experience and current interests of the participants ensured

their high motivation and up-to-date knowledge with respect to the discussed

topics. They were also selected from different roles and positions in order to get a

variety of viewpoints and to ensure the quality of the research.

Data collection methods

There are two types of data: primary data (collected for the first time) and

secondary data (already collected and analysed by someone else) (Kumar 2005).

There are many methods of primary data collection, for example, observations,

surveys and interviews.

In this research, the primary data was collected by using the interview

method via semi-structured interviews and the survey method via questionnaires.

The interview method was selected because it allows the researcher to get as close

as possible to the world of industry and interpret this world and its problems from

the inside, as it is seen and felt at various points and levels (Schwartzman 1993).

The questionnaire method is used to clarify the matter with regards to challenges

and social network issues. Figure 2 illustrates the main methodological choices in

this thesis.

In order to ensure the reliability and validity of the research, data

triangulation and validating the case study reports from the informants are used in

this study. In qualitative research, validity relates to the findings accurately

reflecting the real situation and being backed by evidence (Guion 2002).

Triangulation is a method for checking and establishing validity in the qualitative

research (Yin 2009). In this research, data triangulation is used to weight the

collected data from the different roles and positions of the informants. The

conclusions of the collected data are then shown to informants to confirm and

verify their answers in order to enhance the validity of their responses.

Page 28: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

26

Fig. 2. Main methodological choices in this study.

To conclude, the goal of this research is to enhance the understanding of

knowledge transfer in requirements engineering in the context of collaborative

product development. This study meets the research objective through literature

and empirical studies, which are conducted in a qualitative manner. The literature

and previous research were studied to gain a deeper understanding of the studied

topic and they were used as a knowledge base to design an empirical study. The

empirical research was conducted from multiple case studies to the single case

study. The empirical material was obtained through interviews and surveys of

experienced industrial managers and specialists.

Table 3. Research strategy and data collection methods for each article.

RQ# Research strategy No. of companies Data collection method No. of informants

RQ1 Multiple case studies 5 Interviews 7

RQ2 Multiple case studies 7 Interview and surveys 17

RQ3 Multiple case studies 2 Surveys 16

RQ4 Single case study 1 Interviews 9

RQ5 Single case study 1 Interviews 9

Research Philosophy

Epistemology

Ontology

Positivism

Objectivism

Interpretivism

Subjectivism

Research Approach

Deductive

Quantitative

Inductive

Qualitative

Research Strategy

Multiple cases to single case

Data collection Mixed methods (interviews and surveys)

Page 29: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

27

1.4 Key concepts

The key concepts used in this research are presented in this chapter. There are

four main key concepts in this study: collaborative product development (CPD),

knowledge transfer (KT), social network (SN), and requirements engineering

(RE).

1. Collaborative product development (CPD) is the cooperative relationship

between firms in order to create and develop products. This definition is

based on Lawson-Smith et al. (1991). The focus of CPD in this study is

scoped on the collaboration between buyer and supplier in high-tech

companies.

2. Knowledge transfer (KT) is defined as a process to pass knowledge from one

person to another. Knowledge to be transferred in this study is classified into

four types (Distanont et al. 2012): explicit engineering knowledge, tacit

engineering knowledge, explicit managerial knowledge and tacit managerial

knowledge. This classification follows the original tacit and explicit

classification by Nonaka and Takeuchi (1995), extended with the managerial

and engineering dimension (Distanont et al. 2012). Managerial knowledge is

defined as the skills and techniques for managing and organising design and

development in the collaborative product development process. Engineering

knowledge is defined as a body of knowledge, understandings and practices

that relate to product design and development in the collaborative product

development process. Managerial and engineering knowledge can be either

explicit or tacit.

3. Social network (SN) in this research is a concept to study the pattern of

interaction between buyer and supplier while transferring knowledge in

collaborative product development. This interaction pattern is analysed by

using social network analysis as a tool. This definition is compiled from

Borgatti and Molina (2003), Scott (1999) and Wasserman and Faust (1997).

4. Requirements engineering (RE) in this study is defined on Asghar and Umar

(2010) and Kauppinen et al. (2004). RE is a core process for product

development concerned with understanding stakeholder needs, identifying

what the company intends to build and ensuring product development builds

a product that satisfies those needs at minimum cost and time.

Page 30: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

28

Page 31: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

29

2 Theoretical foundation

2.1 Theoretical framework

This study bases its theoretical foundation on four areas: collaborative product

development (CPD), knowledge transfer (KT), social network (SN) and

requirements engineering (RE). These theories are applied to the extent required

for the objective of a better understanding of knowledge transfer in requirements

engineering in the context of collaborative product development. In order to

understand knowledge transfer in requirements engineering in the context of

collaborative product development, it is necessary to first understand the

background, nature and characteristics of collaborative product development and

knowledge transfer in general. In this study, collaborative product development

includes the product development process, the nature and characteristics of

collaborative product development, supplier collaboration, buyer-supplier

relationships, and the front-end process. The knowledge transfer area includes the

concept of data, information, knowledge, the nature and characteristics of

knowledge transfer, the knowledge transfer process and the critical issues of

knowledge transfer. Afterwards, this chapter goes deeper into social networks and

the requirements engineering area. It is necessary to apply the social network

concept in this dissertation in order to understand the relationships and individual

interactions among buyers and suppliers during knowledge transfer. Social

network includes the fundamental concepts and key elements of social network.

These concepts are actor, relational tie, characteristics of the network and network

structure. The requirements engineering area includes the requirements

engineering process, types of requirements and the critical issues of requirements

engineering. Figure 3 illustrates the theoretical framework of this dissertation.

Page 32: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

30

Fig. 3. Theoretical framework of this dissertation.

According to Figure 3, the dashed line is used to scope the concepts to be studied

in this research. What is inside the dashed line is the concept inside the theoretical

framework. What is outside the dashed line is out of the scope of theoretical

framework however being somehow influencing as a related research.

This chapter provides an overview of the literature that is relevant to this

study. The purpose of this chapter is to conduct a literature review and collect

previous studies that are related to this study in order to help the reader

understand the contents of this dissertation. In addition, it identifies a number of

sources that have made a great contribution to the study. Figure 4 presents how

this chapter relates to the research questions and the main results of the study that

are presented in Chapter 3.

Collaborative Product Development (CPD)

Product development process A concept of collaborative product development Supplier collaboration Buyer-supplier relationships Front-end process

Customer collaboration

Knowledge transfer in requirements engineering

in the context of collaborative product

development

Requirement Engineering (RE)

Social N

etwork

(SN

)

Kn

owled

ge Tran

sfer (KT

)

Basic concepts of social network

(actor, relational ties,

structure and network)

Social capital

Norms

Sanctions

Knowledge types Knowledge transfer processFactors influencing knowledge transfer

Organisationallearning

Internal knowledge management

Requirements engineering process

Types of requirements

System modeling, tools and methodsStakeholders’ analysis

Study

Theories

Page 33: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

31

Fig. 4. Structure of Chapter 2 and its relation to the research questions and Chapter 3.

2.2 Collaborative product development (CPD)

Recently, developing a product or a system has become the vital factor of

competition in many businesses (Cooper 2011) since the new product is the key

element in creating and maintaining the competition advantage (Griffin 1997).

However the product development work is not an easy task since it requires

numerous fields of knowledge, skills and experiences (Cooper 2011). Additionally,

with the severe competition, the technological change and uncertainty and market

and demand instabilities create much more difficulties for development work

(Cetinkaya 2011; Cooper 2011). With such situations, firms cannot rely entirely

on their own resources. They have started to look for other ways handle these

challenging situations by collaborating with other companies to combine the

external capabilities with internal resources. As a result, working in a

collaborative environment becomes a key strategy in the development of products.

CPD is a business strategy that facilitates different companies to work together in

developing a product (Chang & Chu 2004). To do collaboration with other

companies, a business model of the companies may be changed to fit the current

situation (Osterwalder 2004). Changes in the business model impact the changes

in the strategic choices of a company (Shaffer et al. 2005), for example bringing a

supplier to involve in the product development process earlier (Chang & Chu

Chapter 2.2Collaborative product development (CPD)

Chapter 2.3Knowledge transfer (KT)

Chapter 2.4Social network (SN)

theory

Chapter 2.5Requirements

engineering (RE)

RQ 1

RQ 2

RQ 3

RQ 4

RQ 5

Chapter 3.1Challenges of CPD

Chapter 3.2Knowledge transfer pattern

in CPD

Chapter 3.3Individual Interaction pattern

in CPD

Chapter 3.4Challenges of KT in the

RE process

Chapter 3.5Organising KT in the

RE process

Related study Research questions Results

Page 34: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

32

2004). Effective CPD can reduce the development time, reduce the development

cost, quickly respond to the market, strengthen company’s core competence and

remain competitiveness (e.g. Aylen 2010; Baldwin & Clark 2003; Chesbrough

2007). To successful CPD, companies and their partners need to work and

interaction closely as well as information, knowledge, skill and experience need

to be transferred openly and widely. These environments could boost a chance of

new ideas and innovation emerging. Under the concept of open innovation

(Chesbrough 2007), the boundaries between a firm are not the obstacle to create

innovation. Collaborating with other companies is beneficial to utilise external

ideas, skill, expertise and other resources. However these concepts (business

model and open innovation) are out of the scope of this dissertation, they are not

discussed further.

2.2.1 Nature of product development

Due to increasing global competition, product lifecycles have been shortening;

therefore, faster product development is necessary in order to keep up with the

competition. Product development is the process of bringing new products or

services to the market. It involves not only the idea generation, product design

and engineering, but also market research and marketing analyses (Cooper 2011;

Ulrich & Eppinger 2008). Product development must provide a product that

satisfies the customer’s needs and expectations. Such needs and expectations may

relate to a product or a service.

Product development is typically seen as the first stage in generating and

commercialising new products within the overall strategic picture of product

lifecycle management (Ulrich & Eppinger 2008). The purpose of the product

development process is to facilitate quality assurance, coordination of team

members, the planning project schedule and management of the process.

According to Ulrich and Eppinger (2008), product development requires

contributions from all the functions of the organisation and from external sources

such as customers and suppliers. Characteristics that make product development

challenging for the project team are trade-offs, the dynamic nature of the

environment, the level of detail used, time pressure, required investments,

creation, satisfaction of customer needs, team spirit and diversity. The dimensions

used to assess the performance of product development efforts are: product

quality, product cost, development time, development cost and development

capability (Cooper 2011; Ulrich & Eppinger 2008).

Page 35: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

33

There are different types of product development according to different

sources of information depending on the difficulty, newness or uncertainty of the

development process. According to Ulrich and Eppinger (2008), there are four

main types of product development: new product platforms, derivatives of

existing product platforms, incremental improvements to existing products and

fundamentally new products. Cooper (2011) categorises product development

products into platform, development, product development projects and

fundamental research projects. However, it can be seen that even if the nature of

the projects differ, all of the project types mentioned above follow a similar

process.

Product development has been valued as a means to decrease the product

lifecycle and increase sales, profits and competitive advantage (Sivadas & Dwyer

2000). To develop a new product, creativity and a fresh line of thought are very

important. However, product development involves many activities that are very

complex in nature and are not systemically controllable (Cooper 2011; Ulrich &

Eppinger 2008). The insufficiency and lack of variety of knowledge and

information are huge hindrances for creative thinking. Furthermore, several

environmental and technical variables (e.g. requirements, customer needs, time

frame, resources and technology) are continuously changing. These situations

make the new development process unpredictable and complex. Therefore, it is

obviously recognised that the challenges of future product development are the

definition of customer needs, generation of new ideas, resource management,

knowledge and information management and technology management.

Fundamental product innovations take time to develop. The generic nature of

the product development process is presented in Figure 5 which is originally

discussed by Cooper (2011) and Ulrich and Eppinger (2008). It has been divided

into two phases: the product research phase (during which creativity is

encouraged) and the product development phase. The purpose of the product

research phase is to look for new product concepts. This phase is almost purely

conceptual; every idea and innovation is welcomed. The end results of this phase

are the product requirements/product specifications and the product mock-up with

the user’s manual of this not-yet-developed product. Then the market test is

implemented. As a result of test marketing, the product is perhaps shelved until

the right time to begin development or the product design may be refined. The

actual product development is then commenced.

Page 36: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

34

Fig. 5. Product development phases.

There are many studies explaining the product development process. Ulrich and

Eppinger’s model (2008) is one of the most basic product development models. It

groups the activities, focusing on the market need through to the production of the

product and the product delivery. The overall process phases are planning,

concept development, system-level design, detail design, testing and refinement

and production ramp-up. The role of marketing in the project development

process is to define the market opportunity and develop the marketing plan for the

product, whereas the role of design consists of the development of industrial

design and the definition of the technology used, design structure, subsystems and

testing. The role of manufacturing takes care of the practical side of the product

development by defining production plans for the product. Another product

development process model is the ‘Stage-Gate Model’ (Cooper 2011). This model

contains several stages of many parallel activities for each section in the company.

It entails review gates to evaluate progress namely, go, kill, hold or recycle the

process. The main criteria employed for the decision is qualitative criteria or

financial criteria. Figure 6 illustrates the new product development model which

is originally discussed by Cooper (2011) and Ulrich and Eppinger (2008).

Fig. 6. Product development process models.

Discovery

Stage1

Stage2

Stage3

Stage4

Stage5

Gate 1 Gate 2 Gate 3 Gate 4 Gate 5

Idea Screen

Second Screen

Go To Development

Go To Testing

Go To Launch

Post-Launch Review

Scoping Build Business

Case

Development Testing & Validation

Launch

Cooper’s Stage-Gate NPD

Phase 5Production Ramp-up

Phase 4Testing & Refinement

Phase 0Planning

Phase 1Concept Development

Phase 2System-Level Design

Phase 3Detail Design

Ulrich & Eppinger’s Generic NPD

Page 37: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

35

The model of Ulrich and Eppinger (2008) is a content model and Cooper’s model

(2011) is a management model. Ulrich and Eppinger’s model is somehow more

generic than Cooper’s model; Cooper’s model entails a much higher level of

stages and gates. In this research, the researcher employs the NPD process by

Ulrich and Eppinger (2008) to study the knowledge transfer pattern between

buyer-supplier in the collaborative product development context.

In addition to the process of product development, there are another two

processes that relate to the product development process: software development

process and new service development process (NSD). On the one hand, software

development is a process in which customer’s ideas and wishes are translated into

the physical system (Birrell & Ould 1985). Birrel and Ould (1985) divide

software development activities in three categories as follows: 1) planning, 2)

implementation, testing, and documenting and 3) deployment and maintenance. In

the planning stage, the customer’s requirements are translated into the language of

engineers. Customer requirements can be pretty incomplete, ambiguous or even

contradictory sometimes. Requirement engineers analyse the commission and

plan the scope of development. The scope of development should be clearly

stated. At the second stage, the actual software product is created and tested in

order to ensure that not only bugs are recognised and are or will be corrected but

also what is important. After that design and testing documents are created for

further use. The deployment and maintenance stage becomes when the code is

appropriately tested and the management can approve the release.

There are three well known types of software development models: the

waterfall model, the iterative development model and the agile model. The

suitable model depends on the internal and external environment of the project as

well as on the schedule and the objectives of a project and resources allocated.

1. The waterfall development model is the simplest model of the software

development process and purely sequential. The project team should move to

the next phase only when the current phase is completed (Birrell & Ould

1985). The waterfall development model has its origins in the manufacturing

and construction industries, highly structured physical environments

(Benington 1983). The advantage of waterfall development is that it allows

departmentalisation and managerial control. A schedule can be set with

deadlines for each stage of development. The disadvantage of waterfall

development is the lack of feedback loops.

Page 38: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

36

2. Iterative software development models are especially preferred by

commercial developers because they have potential of reaching the design

goals of a customer who does not know how to define what they want

(Larman & Basili 2003). The one example of the iterative development

model is prototyping (Davis 1992). As customers cannot always specify their

requirements, prototypes can be a way to increase the flexibility of the

development process by allowing the customer to interact and experiment

with a working representation of the product (Davis 1992).

3. Agile software development models (e.g. Boehm 2002; Cockburn 2002;

Martin 2002) are built on the foundation of iterative development. Compared

with the iterative approach they add a lighter, more people-centric viewpoint

in. The one example of the agile software development model is Scrum.

Scrum is an agile project management methodology (Schwaber 2004). It is a

skeleton that includes a small set of practices and predefined roles that can be

applied in different kinds of situations. The core of the Scrum model is the

systems development that involves several environmental and technical

variables for example requirements, a time frame, resources and technology

that are to change during the process therefore this makes the development

process complex and difficult to predict (Schwaber 1995).

The successful of usage agile methods depends on the selection of agile methods.

Cockborn (2000) presents that agile methods should be selected based on project

size, criticality and priority. Also to reach the highest potential of agile methods

used in the development process, those methods need to be adjustable for

different situations (Abrahamsson et al. 2003).

On the other hand, new service development (NSD) is the organisational

process. It links between the capability of marketing and operation to envision,

design and implement a service valued by customers (Tatikonda & Zeithaml

2002). The first research in the field of NSD is available in the new product

development (NPD) literature, which can be viewed while developing services

(Cooper 2011). Services differ from physical goods in a sense that the service is

produced and used at the same time and it cannot be stored. Developing a service

is also more complex than developing a product since the service needs to be

taken care of both during and after development (Johne & Storey 1998). Close

interaction with customers is a very important element of service development. It

is beneficial not only to sell the existing service, but also to bring the customers to

be users of the other services (Johne & Storey 1998). Innovation in services is

Page 39: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

37

easier to imitate than in products because the changes in processes and procedures

are small and incremental (Atuahene-Gima 1996). Changes in service innovation

could be related to, for example, the service concept, the client interface, the

delivery system and technological options (Den-Hertog 2000; Gallouj &

Weinstein 1997). There are four characteristics of service need to be considered:

intangibility, inseparability, variability and perishability (Shekar 2007). These

characteristics make service cannot be examined before purchase and difficult to

concretise and test throughout the development process.

The process of service development is similar to the product development

process but there are differences in the activities and the research techniques

(Shekar 2007). It is less likely to focus on predevelopment activities, concept tests,

test marketing and launch activity. The NSD process comprises three main stages:

the front end, the back end and product introduction (Tatikonda & Zeithaml 2002;

Odor 2010). 1) The front end stage includes strategic positioning, idea generation

and concept development. The front end stage relates to ideas about what service

concept should be developed (Edvardsson et al. 2000). It should start from a

thorough description of customer requirements and how service can meet those

requirements to the customer’s satisfaction. 2) The back end stage implements the

chosen service concept. It includes concept implementation and full prototype

tests. 3) The product introduction stage is about to manage the service during and

after its introduction. This stage includes market rollout and performance

evaluation. Figure 7 illustrates the new service development process which has

been originally discussed in Edvardsson et al. (2000), Odor (2010), Shekar (2007)

and Tatikonda and Zeithaml (2002).

Strategic positioning

Idea generation

Concept development

Concept implementation

Testing

Market rollout

Performance evaluation

Front end stage Back end stage Product introduction stage

Fig. 7. New service development process.

Cowell (1988) emphasised that the character of service development is the

process that is driven by technology rather than by the user. Cowell (1988) further

emphasised service improvements are more important than service innovations,

Page 40: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

38

users play a key role in the service production process whereas service staff are

critical to both service production and delivery. Additionally, the rate of new

service creation is faster but user adoption of new services is slower when

compared with new products.

In summary, the previously stated concepts of product development, software

development and service development are similar. The sharing of information and

knowledge is the heart activity of these processes. Successful new product,

software and service development needs successful transferring information and

knowledge among stakeholders.

2.2.2 The concept of collaborative product development

The concept of collaborative product development originated from Lawton-Smith

et al. (1991). They defined this as the cooperative relationship between firms in

order to create and develop new products. Emden et al. (2006) defined

collaboration as a type of cross-organisational linkage, which in addition to high

levels of integration is characterised by high levels of transparency, mindfulness

and synergies in participants’ interactions. According to the literature, in addition

to the term ‘collaboration’, other terms are also used, such as ‘cooperation’ or

‘partnership’.

Company collaboration can be classified into two categories: internal and

external collaboration. An external collaboration is defined as a firm’s

collaboration with a supplier, a competitor or a university. Even though internal

and external collaboration norms are similar, external collaboration may stimulate

internal collaboration (Hillebrand & Biemans 2004). There are several forms of

external collaboration including joint ventures, joint R&D agreements, licensing

agreements, buyer-supplier collaboration and so on. Companies may collaborate

with partners at various stages of the value chain, such as their customers or

suppliers during product development. The companies need to collaborate with

the partner because they want the highest efficiency in developing and producing

the new products (Blonder & Pritzl 1992; Hamel et al. 1989; Littler et al. 1995;

Millson et al. 1992).

It is difficult for one company to single-handedly develop a product, because

it is very difficult for a company to be an expert in every area. Therefore,

companies need to rely on other companies’ skills, knowledge and resources,

which they are lacking, in order to develop the new product. To access the skills,

knowledge and resources as much as possible, it is crucial to drive the

Page 41: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

39

collaboration among companies so that the resources can be shared and

consequently lead to the firm’s innovative capability. The important sources of

those resources are from the partners. One of the purposes of inter-firm

cooperation is to obtain knowledge from partner firms (Grant & Baden-Fuller

2004). Thus, the collaboration is a form of knowledge transfer for developing

new knowledge (Simonin 1997; Poppo & Zenger 1998) and it is considered very

important for driving the product development capability (Aylen 2010; Oh &

Rhee 2010). In collaborative product development two or more firms work

together, with the specific purpose of developing products. Possible collaboration

partners are for example, customers, competitors and suppliers. This research

concentrates on buyer-supplier collaborative product development.

The collaboration between buyer and supplier in the product development

process has become a vital issue for companies to strengthen their core

competence and maintain their competitive advantage. Several studies indicate

that the benefits of collaborating on product development include reducing the

cost and risk of products, improving the quality of products, improving time to

market, satisfying customer requirements, accessing the necessary technologies,

skills and knowledge, accessing a larger potential market, responding to changes

in technology and sharing ideas (e.g. Aylen 2010; Baldwin & Clark 2003;

Chesbrough 2003; Hoegl & Wagner 2005; Kent 1991; Littler et al. 1995; Sivadas

& Dwyer 2000). However, collaborative product development also encounters

many challenges. Littler et al. (1995) studied collaborative product development

in the information and communication technology sectors. They found that the

frequency of communication between partners, mutual trust and the contribution

of collaborating between partners as expected are the most critical factors related

to the process of collaborative product development. Parker (2000) and Ragatz et

al. (1997) claimed that trust between partners is essential for successful

collaborative relationships. In addition, some studies indicate the risks of

collaborative product development. Hamel et al. (1989) and Littler et al. (1995)

indicate that leakage of a firm’s skills, experience and knowledge is a risk of

collaborative product development. Ohmae (1989) suggests that collaborating

partners should clearly arrange the roles and responsibilities between partners,

otherwise there is the possibility of one organisation losing direct control over the

product development process. Differences in the aims and objectives between

partners are considered as a risk of collaborative product development. There is

also another risk that affects collaboration: the additional budget and time cost for

establishing and managing collaborating partners (Farr & Fischer 1992).

Page 42: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

40

2.2.3 Buyer-supplier relationships

Relationships are important in business. A company’s performance depends on

the performance in the individual relationships both inside and across companies

(e.g. Anderson & Narus 1990; Anderson et al. 1994; Dwyer et al. 1987;

Håkansson & Snehota 1995). This research focuses on business relationships

where there are only two parties: a buyer and a supplier. Håkansson and Snehota

(1995) present the four main structural characteristics of business relationships,

especially in the buyer and supplier relationship. 1) Firstly, the continuity and

stability of relationships which are gradually built up depend on the age of the

relationship. 2) Secondly, the complexity which causes not only from the number,

type and the pattern of individual interaction but also the scope and established

relationship. 3) Thirdly, the symmetry which business relationships tend to have

balance in terms of resources and initiative of the parties involved. 4) Finally, the

informality which informal bonding is more important than formal contracts in

keeping a good relationships and building trust between parties. A relationship

between two companies can be characterised by an actor, activity, and resource

(Anderson et al. 1994; Håkansson & Snehota 1995). Actors develop mutual bonds

of commitment and trust between companies. Actors perform activities and adjust

their activities to the partner’s activities if needed (Håkansson & Snehota 1995).

When the activities are linked, needed resources (physical resources or

knowledge) can be accessed and acquired by the partner (Håkansson & Snehota

1995). Thus, two parties can learn about each other’s resources and utilise these in

order to create something new or improve the current practices through

collaboration.

In general, the relationships between buyers and suppliers in developing the

product are diverse and they are developed consecutively. Gules and Burgess

(1996) have emphasised that the buyer and supplier relationships are often

characterised according to two major types: adversarial and collaborative (Imrie

& Morris 1992; Lamming 1986; Lyons et al. 1990). The adversarial relationship

or traditional relationship is referred to as an ‘arm’s-length’ relationship, which

has the characteristics of tough negotiation, focus on price, short-term contracts

and multiple sourcing (Matthyssens & Van den Bulte 1994). The competition for

suppliers was defined by the buyer. The buyer would ask many suppliers to bid

for business and use the enquiry and post-bid negotiation process to reduce the

piece price. The supplier with the lowest bid would be awarded the contract. This

type of relationship sees the buyer-supplier relationship in terms of both parties

Page 43: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

41

competing with each other for profit margin. In this atmosphere, the sharing and

transfer of data and information were very limited and this relation tended to

discourage innovation in the supplier. Therefore, with the ineffectiveness of such

relationships and also the globalisation of markets, combined with a restructuring

of many firms towards a focus on costs, quality, flexibility and technology, a new

relationship between buyers and suppliers has emerged – a more collaborative

approach within the partnership relationship (Herbig & O’Hara 1995; Macbeth &

Ferguson 1994).

A partnership relationship requires trust and commitment for long-term

cooperation along with a willingness to share risks (Humphreys et al. 2001).

Buyers and suppliers achieve lower costs through working together to lower both

the buyer’s and seller’s operating costs (Wilson 1995). In the partnership model,

suppliers become involved in the NPD process much earlier than before.

Lamming (1993) showed the results of involving suppliers in the development of

a new vehicle, which gave the Japanese a major advantage, and he also asserted

that earlier involvement and key aspects of participation in NPD is a feature of

collaborative relationships. Many manufacturers now recognise that their ability

to become world-class competitors is based to a great degree on their ability to

establish high levels of trust and cooperation with their suppliers, since they

believe that their suppliers are able to help them to achieve a stronger competitive

position (Humphreys et al. 2001). Many researchers (e.g. Ellram 1990; Lammin

1986; Wilson 1995) studied the key success factors for collaborative relationships.

The common key success factors that affect the relationships between partners are

commitment, trust, cooperation, shared knowledge/technology and social bonds

(Bensaou 1999; Lang 2004).

2.2.4 Supplier collaboration in collaborative product development

Firms collaborate with suppliers in product development in order to gain access to

the supplier’s capabilities (Zirpoli & Camuffo 2009). The supplier can provide

insight into the production process required for purchased items and can optimise

the design around feasible production processes to reduce costs and

manufacturing cycle time (Birou & Fawcett 1994; Monczka et al. 2000; Wynstra

et al. 2001). Buying firms also expect suppliers to provide direct design and

production support in areas that are not a core focus or technology emphasis of

the master firm. Therefore, the participation of the supplier in product

development projects can help reduce costs, reduce concept to customer

Page 44: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

42

development time, improve quality and provide innovative technologies that can

help capture market share (Peterson et al. 2003; Song & Di Benedtto 2008; Lau et

al. 2010; Oh & Rhee 2010; Un et al. 2010). There are two issues that companies

should consider when making a decision to collaborate with a supplier. First, the

level of responsibility (degree of supplier involvement) the supplier will be

assigned in the project and the stage of the product development cycle at which

the supplier will be integrated (time of involvement).

The degree of supplier involvement varies according to the purpose and need.

Koufteros et al. (2007) classified the degree of supplier involvement into grey-

box and black-box. A grey-box is defined as the supplier’s responsibility for

product development – providing expertise, suggestions and other input. On the

other hand, the degree of supplier responsibility is higher for the black-box.

Suppliers can be trusted to develop parts, components or subassemblies.

Additionally, Peterson et al. (2005) have adopted the model of supplier level of

responsibility proposed by Handfield et al. (1999) and Monczka et al. (2000) by

classifying the level of the supplier’s responsibilities ranging from zero

responsibilities to the supplier controlling the design (for example black-box

suppliers). Suppliers that have few responsibilities with regards to product design

are kept distant and are only involved in the later stages of product development.

White box suppliers are integrated only informally and they are used for external

consultation assistance. Grey box suppliers are formally involved in the

collaborative development process and finally black box suppliers provide the

organisation with their expertise and core competence.

Furthermore, there are some studies that point out the form of inter-firm

collaboration. The different forms of inter-firm co-operation can be classified by

the different degrees of supplier involvement in product development. The three

most important forms of collaboration are contract development, coordinated

development and joint development. The most basic form of collaboration is

contract development, which is based on the contract with the suppliers. The

supplier is involved in the product development only in coordinating meetings,

not requiring the transfer of knowledge or other input (Moskalev & Swensen

2007). This form is used when the supplier lacks the resources or knowledge to

develop a product. Coordinated development is defined as a form in which

suppliers can be involved in developing the separate components of the product.

The final form is joint development. In this form, suppliers are integrated into the

development team in order to collaborate in product development. Knowledge,

skills, experiences or other resources are shared. Fliess and Becker (2006) studied

Page 45: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

43

the intensify co-operation between companies and classified it from the lower

level (internal development, know-how exchange) to the higher level (coordinated

development, joint development and contractual joint ventures). Additionally,

Hsieh (2011) classified the degree of intensity in inter-firm collaboration by

adopting the collaboration classification of Petersen et al. (2005) and Fliess and

Becker (2006). Hsieh’s (2011) study defines and classifies the degree of different

intensities of inter-firm collaboration between the convenience store chains and

their suppliers in service development. Hsieh (2011) classified the degree of

collaboration intensify by using the degree of the supplier responsibilities in the

specification design related to the decision-making process as a criterion (Table 4).

Table 4. Intensity of inter-firm collaboration.

Intensity of inter-firm collaboration Detail

Contract development A contract is used to define the responsibilities of the buyer and

supplier in a product development project. The buyer’s and

supplier’s development activities are separated.

Coordinated development The responsibility of the supplier varies from just giving

information to taking charge in developing some part of the

product.

Asymmetrical cooperation Detailed specification information is provided for developing the

final product/service.

White-box cooperation Informal discussion about specifications occurs.

Grey-box cooperation Knowledge/information is transferred between the buyer and

supplier and joint decision-making occurs.

Black-box cooperation Most design work is the responsibility of the supplier. The buyer

takes charge of reviewing the design specifications.

Systems partnership The supplier is integrated into the development process to

develop the complex part of the product.

Joint development The buyer and supplier collaborate as a team to develop the

product.

In addition to the degree of supplier involvement, the time of involvement is

another key issue in supplier involvement. Ansari and Batoul (1994) studied the

role of suppliers in product development from the conception stage through to the

final delivery stage. They outlined four phases of the suppliers’ roles. 1) Firstly,

the product planning phase in which suppliers can provide expertise in analysing

customer requirements and generating a list of new product ideas. 2) Secondly,

the parts deployment phase in which suppliers can provide alternative design

concepts and estimate the manufacturing costs of various parts. 3) Thirdly, the

Page 46: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

44

process planning phase in which the supplier can determine their own existing

processes’ constraints. 4) Finally, the production planning phase in which

suppliers can help develop performance measurement criteria for production

planning. However, involving suppliers early has become a key strategy (Wagner

& Hoegl 2006). Early supplier involvement was proposed by Dowlatshahi (1998).

He presented several activities for various involved actors during manufacturer-

supplier collaborations for implementing supplier involvement in the early phase

of the product development process. There are many benefits to be gained from

engaging suppliers in the early phase of product development (Bozdogan et al.

1998; Dowlatshahi 1998). Firms can receive ideas, suggestions or comments on

the product design from their suppliers in the early development phase where it is

easier to develop and make changes at a lower cost. Moreover, early involvement

of suppliers is necessary when the product development process in question

involves high complexity and uncertainty.

Therefore, according to the literature, it can be seen that the scope of

involvement degree of the supplier in the product development process can be

extensive, from participation in simple consultation on design ideas, until the

proposition of a final product’s new formulation. Suppliers can be involved at any

phase in the development process according to the purposes and needs of firms

and their suppliers.

2.2.5 Front-end of innovation process

Successful development process depends heavily on the early phases of product

development. According to Hertenstein and Platt (1998) about 75% to 90% of

product costs result from the predevelopment phase of the development process;

the front-end phase. The front-end phase of a project is the period between when

the project idea is emerged and considered and when the final decision of

developing is made (Kim & Wilemon 2002). Nobelius and Trygg (2002) present a

front-end model that encompasses many activities: the mission statement, concept

generation, concept screening, concept definition, business analysis and project

planning. The output from the front-end phase is a business plan associated with

corporate strategy, a well-defined product concept and clear and complete product

requirements for the rest of the development phases (Kim & Wilemon 2002; Reid

& Brentani 2004). All the project uncertainties, all the project conditions and all

the unpredictable situations are presented in the front-end phase (Kim & Wilemon

Page 47: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

45

2002; Khurana & Rosenthal 1997; Koen et al. 2001; Nobelius &Trygg 2002).

Information and knowledge can be seen to flow during this phase and many

important decisions in the project are made during this phase. Therefore, the

decisions made in this phase could create a significant impact on the project

results.

Kim and Wilemon (2002) point out factors that influence the performance of

the front-end phase. These factors are divided into internal and external factors.

The internal factors consist of the front-end idea and the front-end team. People

working on the front-end project can impact the front-end phase performance

since they play a key role in collecting and managing the front-end idea. The

front-end idea can directly impact the front-end phase performance since the

front-end idea will develop into a complete and validated product concept and

product requirements which act as the guideline in producing a product or a

service. The external factors may include, for example senior management,

functional groups, customers, suppliers, partners, regulators and competitors. The

new ideas, information or knowledge may come from these people. Information

and knowledge are very crucial for the front-end phase and should be considered

at the beginning of the process. The generation of ideas and the selection of the

right product ideas are required reliable information and in-depth knowledge and

experience (Kim & Wilemon 2002). Therefore, to achieve the front-end phase,

management level has to effectively organise the information and knowledge flow

provide enough channels for accessing information and knowledge (Kim &

Wilemon 2002). Besides Kim and Wilemon (2002), also Koen et al. (2001)

present many factors influencing the front-end phase, including for example,

operational capacities, customer, competitors, enabling science and technology,

government policy, regulations and socioeconomic trends. They describe that all

these factors affect the people’s thoughts and actions which consequently as a

contributor to create new ideas. As mentioned previously, well-organised front-

end phase provides many great opportunities to improve the overall development

capability even though this phase represents the weakest and most troublesome

phase of the whole development process (Kim & Wilemon 2002; Koen et al. 2001;

Nobelius & Trygg 2002; Reid & Brentani 2004; Zhang & Doll 2001).

Page 48: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

46

2.3 Knowledge transfer (KT)

2.3.1 Data, information, knowledge

Data, information and knowledge (D/I/K) are very important assets for

organisations. Although D/I/K are different, they affect each other. The distinction

among D/I/K has been addressed by many scholars (e.g. Nonaka & Takeuchi

1995; Davenport & Prusak 2000; Quigley & Debons 1999; Bierley et al. 2000).

Data comprises raw facts and figures that do not have any meaning themselves

[until they are processed into context to give them meaning] (Tuomi 1999).

Information is active data that has been processed within or into context to give it

meaning. Information consists of facts and data that are organised and interpreted

to describe a particular situation, usually in the form of a document or an audible

communication (Ackoff 1989; Davenport & Prusak 2000; Bierley et al. 2000).

Knowledge is information that is combined with context, interpretation, reflection,

truths, beliefs, perspectives, experience, judgements, methodologies and know-

how (Nonaka & Takeuchi 1995; Probst et al. 2000; Bhatt 2001). Knowledge is

ready to be applied to decisions and actions. However, the distinction among data,

information and knowledge has been addressed by many scholars (Table 5).

Table 5. D/I/K according to various authors.

Author(s) Data Information Knowledge

Ackoff (1989) Symbol Data that are processed to be

useful; provides answers to

‘who’, ‘what’, ‘where’ and

‘when’ questions

Application of data and

information; answers ‘how’

questions

Wiig (1993) - Facts organised to describe a

situation or condition

Truths and beliefs,

perspectives and concepts,

judgments and expectations,

methodologies and know-how

Nitecki (1993) Unprocessed,

unrelated raw

facts or artefacts

Data or knowledge processed

into relations (between data

and recipient)

Information scripted into

relations with recipient

experiences

Nonaka & Takeuchi

(1995)

- A flow of meaningful messages Commitments and beliefs

created from these messages

van der Spek &

Spijkervet (1997)

Not yet interpreted

symbols

Data with meaning The ability to assign meaning

Page 49: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

47

Author(s) Data Information Knowledge

Davenport (1997) Simple

observations

Data with relevance and

purpose

Valuable information from the

human kind

Davenport & Prusak

(2000)

A set of discrete

facts

A message meant to change

the receiver’s perception

Experience, values, insights

and contextual information

Quigley & Debons

(1999)

Text that does not

answer questions

to a particular

problem

Text that answers the

questions ‘who’, ‘when’, ‘what’

or ‘where’

Text that answers the

questions ‘why’ or ‘how’

Probst et al. (2000) - - The whole body of cognitions

and skills that individuals use in

order to solve problems

Bierly et al. (2000) Raw facts Meaningful, useful data Clear understanding of

information

Vicari et al. (1996) Representations

of facts, collected

by someone for a

purpose

One’s action of shaping reality,

giving sense to signals or data

Information organised by

somebody for a purpose

Oppenheim et al.

(2003)

Raw material of

information,

typically numeric

Data that is collected together

with commentary, context and

analysis so as to be meaningful

to others

Combination of information and

a person’s experience, intuition

and expertise

Aadne et al. (1996) summarise the different views of several researchers

concerning general assumptions about knowledge: knowledge represents a pre-

given world, knowledge is universal and objective, knowledge results from

information processing, knowledge is transferable and knowledge enables

problem-solving.

Nonaka and Takeuchi (1995) try to explore the difference between

information and knowledge. They stated that information is a flow of messages,

and knowledge is created by the flow of information, anchored in the beliefs and

commitments of its holder. Another way to make a distinction between

information and knowledge is Starbuck’s (1992) study. He states that knowledge

is a stock of experience rather than a flow of information. He suggests that

knowledge relates to information in the same way that assets relate to income.

Therefore, the distinction between information and knowledge is understood as

the degree to which information is processed and put into a practical context.

Brown and Duguid (2000) state that knowledge and information are often

Page 50: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

48

interchangeable and they also propose three generally accepted distinctions

between knowledge and information. Firstly, knowledge usually involves a

knower. Secondly, knowledge appears harder to attach than information. For

example, information is easy to find, possess, accumulate, compare and put in a

database whereas knowledge is less easy to pin down. The third distinction is that

knowledge seems to be something we digest rather than just hold. These

distinctions should initiate a shift from processes to people and the absorption of

information into the mind, understanding and sense-making. Information cannot

be converted to knowledge without the social human process of shared

understanding and sense-making of information.

According to the literature, the researcher concludes that data is raw

knowledge without meaning or interpretation. Information is data that have been

given meaning and put into context. This research concentrates on knowledge.

Knowledge can be transferred either directly between individuals through

socialisation, or indirectly by sending information that people can make meaning

of and internalise as their personal knowledge.

2.3.2 Types of knowledge

Knowledge is an essential resource of firms (Blumenberg et al. 2009). Nonaka

and Takeuchi (1995) state that knowledge is a strategic resource for emerging

innovation and developing new products. The effective process and utilisation of

knowledge leads to the creation of new products or innovation. The development

of a product relies on information and knowledge to achieve its core activities,

therefore at various phases of product development, it is necessary to use many

kinds of information and knowledge. These may include, for example, customer

information, supplier information, product specifications, skills, experiences, new

technologies and know-how.

Knowledge can be classified in several ways. The wide citation of knowledge

classification is the work of Nonaka (1994), which is based on Polanyi (1962).

Knowledge was classified into two dimensions: tacit and explicit. Explicit

knowledge is objective and rational knowledge that can be easily expressed,

communicated and transferred into words, sentences, numbers or formulas

(context free) (Nonaka & Takeuchi 1995). It can include, for example, theoretical

approaches, problem-solving, manuals, databases, training tools and standard

operating procedures (e.g. Awad & Ghaziri 2003; Bloodgood & Salisbury 2001;

Cavusgil et al. 2003; Desouza & Awazu 2004; Grant & Baden-Fuller 2004;

Page 51: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

49

Inkpen & Pien 2006; Kogut & Zander 1992; Lee 2001; Lunghua et al. 2010;

Nonaka & Takeuchi 1995; Small & Sage 2006; Spender 1996). Tacit knowledge

is subjective and experience-based knowledge that is difficult to articulate,

express and communicate to others in words. This also includes, for example,

cognitive skills such as beliefs, images, intuition and mental models, as well as

technical skills such as craft and know-how (Hall & Andriani 2002; Koskinen &

Vanharanta 2002; Kikoski & Kikoski 2004; Lee 2001; Lunghua et al. 2010;

Nonaka 1994; Polanyi 1962; Spender 1996). In the product development context,

explicit knowledge may exist in specifications, instructions and documents

whereas tacit knowledge may exist in the manager’s experience of designing and

testing.

Furthermore, there are other ways to characterise knowledge. Some refer to

knowledge as declarative (know-that, know-why or know-when) and procedural

(know-how) (Cohen 1991; Huber 1991; Kogut & Zander 1992). Declarative

knowledge – which is about facts, events or propositions (Cohen 1991) – consists

of statements that provide a description. It is not committed to a specific use and

can be consciously and intentionally recollected. In the product development

context, it includes, for example product features and product drawings. In

contrast, procedural knowledge is related to how things are done (Cohen &

Bacdayan 1994). It is automatic and inarticulate. In the product development

context, it includes, for example, skills in development and testing. Some classify

knowledge into these dimensions: categorised knowledge to codification,

teachability and observability (Winter 1987; Zander & Kogut 1995), whereas

many scholars (e.g. Bou-Llusar & Segarra-Cipres 2006; Hansen 1999; Inkpen &

Dinur 1998; Simonin 1999; Szulanki 1996) propose dimensions of knowledge

according to how hard it is to transfer: tacit and explicit, complex and simple,

specific and non-specific, and systematic and autonomous. In addition to those

dimensions of knowledge, Brusoni et al. (2001) classified knowledge into two

categories: technological knowledge and managerial knowledge.

Page 52: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

50

Table 6. Characteristics of tacit and explicit knowledge.

Tacit knowledge Explicit knowledge

- Context-specific - Non-context-specific

- Procedural - Declarative

- Complex - Simple

- Personal, part of everything that we can do and

say

- Written knowledge (books, manuals, etc.)

- Hard to formalise and communicate - Easier to identify

- Integral to our thinking, it is deeply embedded in

the way that we work

- Can be stored as artefacts in different systems,

can be identified, measured and audited

In this research, the researcher has classified knowledge into four types; namely,

explicit engineering knowledge, tacit engineering knowledge, explicit managerial

knowledge and tacit managerial knowledge (Figure 7). Managerial knowledge is

defined as the skills and techniques for managing and organising design and

development in the collaborative product development process. Engineering

knowledge is defined as a body of knowledge, understandings and practices that

relate to product design and development in the collaborative product

development process. Managerial and engineering knowledge can be either

explicit or tacit.

The researcher defined information as explicit knowledge. Data, on the other

hand, does not have meaning of itself. However, data is relevant to these four

fields of knowledge when it has been given meaning through context and it then

transforms into the information. Data, on its own, is not relevant to these four

fields of knowledge. Thus, for these reasons, we leave data by itself out of this

study, because it is not included in the knowledge classification and knowledge

definition.

Fig. 8. Classification of knowledge (Distanont et al. 2012 published by permission of

Inderscience).

Tacit managerial

knowledge

Tacit engineering

knowledge

Explicit engineering

knowledge

Explicit managerial

knowledge

Managerial Engineering

Tacit

Explicit

Page 53: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

51

2.3.3 The knowledge transfer process

Firms attempt to continuously generate new ideas and knowledge in order to

develop new products and perform beyond competitors and keep a long-term

successful and competitive advantage (Teece 1998). However, without the

transfer of knowledge, those new ideas and new knowledge cannot attain the

greatest value for creating innovation. Therefore, the success of an organisation

depends on its ability to create and transfer knowledge (Davenport & Prasak

2000), since the transfer of knowledge provides a basis for competitive advantage

in firms (Argote & Ingram 2000) and helps in keeping profitable growth,

especially for high-tech companies. High-tech industries are dynamic and

intensely competitive markets. High-tech products are complex and require

constant innovation, knowledge and skills in multiple fields in order to meet

continuous changes in market and customer needs (George et al. 2001). Therefore,

it is difficult for one firm to rely only on internal knowledge and skills or master

all knowledge internally. Firms need to access external knowledge and skills by

joint development with their partners in order to create innovative products

(Zahra & Bogner 2000). According to Yang and Kim (2007), the improvement of

organisational performance originates from the transfer of knowledge between

buyer and supplier. The buyer needs knowledge and skills from the supplier to

bring that knowledge to produce quality products at a low price to maintain their

profit and competitiveness in the long term. On the other hand, a supplier requires

knowledge from the buyer in order to develop and help to identify parts that can

be most efficiently and effectively produced given their production capability.

These situations have forced companies to form a collaborative development with

their partners in order to gain learning and new knowledge by transferring (Soini

2007).

Knowledge transfer is an important part of knowledge management

(Davenport & Phusak 2000). It refers to ensuring that knowledge is transferred

throughout the company or between organisations from the sender to the receiver

who needs that knowledge. The term ‘transfer’ seems to imply that all the

knowledge is passed from one person to another. Based on simple logical thinking,

knowledge transfer must take place between (at least) two parties. It implies the

giving and taking of knowledge within a context by the participants. Knowledge

transfer can be conceptualised in many different ways. For example, Szulanski

(1996) conceptualises knowledge transfer as a communication process. He

defines knowledge transfer as “the dyadic exchange of organisational knowledge

Page 54: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

52

between a source and recipient”. In other words, the knowledge transfer between

people leads to the learning process of a person and even of the company. It can

be considered as the communication between the source of the knowledge and the

knowledge receiver. Both parties must be satisfied and trust each other in doing so.

Dixon (2000) states that there are five methods of knowledge transfer: serial

transfer, near transfer, far transfer, strategic transfer and expert transfer. Each

method of knowledge transfer is suitable for each specific situation depending on

the type of knowledge to be transferred, the nature of the task and who the

receiver of that knowledge will be. Additionally, Argote and Ingram (2000) define

knowledge transfer as “the process through which one unit (e.g. group,

department or division) is affected by the experience of another”. According to

Argote and Ingram, knowledge is embedded in three basic reservoirs – members,

tools and tasks – and it can be transferred by moving a reservoir from one unit to

another unit or by modifying a knowledge reservoir at a recipient’s site. They also

claim that knowledge transfer occurs through personnel movement, training,

communication, observation, technology transfer, products, replicating routines,

interaction with suppliers and customers, alliances and other forms of inter-

organisational relationships.

Knowledge transfer can either take place within firms (intra-firm knowledge

transfer), or across firm boundaries (inter-firm knowledge transfer). Inter-firm

knowledge transfer may lead to downstream (with customers), upstream (with

suppliers, universities and other organisations) or horizontal (with competitors)

knowledge flows. Inter-firm knowledge transfer is the process of companies

learning from each other. It is difficult for one firm to rely only on internal

knowledge and skills or master all knowledge internally. This inter-organisational

learning may be considered as two processes (Chen et al. 2006):

– Inter-individual learning between companies

– The individual learning is converted into organisational learning through

organisational internal mechanisms after the individual recipient has acquired

the required knowledge.

There are many researchers who have studied knowledge transfer. Some of them

focus on inter-firm knowledge transfer (Table 7), whereas others concentrate on

intra-firm knowledge transfer (Table 8).

Page 55: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

53

Table 7. Study of inter-firm knowledge transfer.

Author Description

Albino et al. (1999) The paper conceptualises the knowledge transfer process as consisting of

two dimensions: an information system and an interpretative system. It

analyses the role of the knowledge transfer between customers and

suppliers in industrial districts. The research results show that the

effectiveness of knowledge transfer between customers and suppliers can be

increased by modifying the knowledge and adopting different types of supply

relationships.

Appleyard (1996) The paper identifies and examines the mechanisms and determinants by

which technical knowledge is disseminated in a knowledge-intensive industry

by comparing Japanese and US companies. The empirical evidence shows

that both public and private mechanisms are used for inter-firm knowledge

sharing. Moreover, knowledge sharing between organisations is considered

to be the improvement of strategic plans, inclusion in professional networks

and coordination of industry.

Chen et al. (2006) The paper discusses the importance of external knowledge and inter-firm

knowledge transfer in small and medium enterprises (SMEs) in the UK. The

results demonstrate that external knowledge is very important and a specific

inter-organisational knowledge transfer process to acquire the required

knowledge is needed. However, the results show that knowledge transfer

between organisations is complex and causes many problems.

Chong et al. (2011) The paper investigates inter-firm knowledge transfer needs and practices

among SMEs. Nine important areas have been the focus of this study, i.e.

the importance of external knowledge; the extent to which external

knowledge is more important to organisational success than internal

knowledge; areas in which insufficient knowledge contributes to costly errors

or mistakes; involvement in knowledge transfer activities; number of social

networks involved; perceptions about networks; use of tools and

technologies to transfer inter-organisational knowledge; constraints of inter-

organisational knowledge transfer; and the effectiveness in leveraging

knowledge.

Inkpen & Tsang (2005) Networks are characterised by social capital constructs and are related to the

transfer of knowledge between network members both at intra-firm networks,

strategic alliances and industrial districts.

Gupta & Govindarajan

(2000)

The paper proposes an inter-organisational knowledge transfer model and

explores the factors that affect this model.

McEvily et al. (2000) The paper discusses the dilemma that while ambiguity slows the diffusion of

superior practices and technologies across firms, it impedes the creation of

new knowledge within the firm.

Mowery et al. (1996) The paper analyses the effects of inter-firm knowledge transfers within

strategic alliances on partner firms’ technological capabilities.

Page 56: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

54

Author Description

Postrel (2002) The paper discusses the dilemma that the economy depends for its

efficiency upon a drastic separation of knowledge across individuals and

organisations, yet studies of product development find that greater

knowledge commonality is associated with better firm performance.

Simonin (1999) The paper explores the role of causal ambiguity on technological knowledge

transfer, where ambiguity is seen as a mediator of antecedents on

knowledge transfer.

Spencer (2003) The paper explores the relationship between firms’ strategies of sharing

knowledge with their innovation system and innovative performance. The

research results confirm that sharing knowledge relates to the degree of

innovative performance. The firms that shared knowledge with their

innovation system and the firms that interacted with their global innovation

system gained higher innovative performance than firms that did not.

Table 8. Study of intra-firm knowledge transfer.

Author Description

Argote & Ingram (2000) The paper conceptualises knowledge transfer as reservoirs of knowledge in

organisations. Knowledge is embedded into members, tools and tasks. It can

be transferred by moving a reservoir from one unit to another unit or by

modifying a knowledge reservoir at a recipient’s site.

Hansen et al. (2005) The paper provides an analysis of social networks and how these are inter-

linked with knowledge sharing outcomes. The empirical evidence shows that

the different subsets of network, such as within-team and extra-team subsets

affected the outcomes of knowledge sharing. The results also show that the

network size has different impacts at the different subsets of network.

Nonaka & Takeuchi (1995) The paper proposes a knowledge transfer model consisting of socialisation,

externalisation, combination and internalisation. Knowledge can be created

and transferred through these processes.

Osterloh & Frey (2000) The paper links the importance of intrinsic and extrinsic motivation to

different organisational forms in analysing how knowledge is generated and

transferred.

Schotter & Bontis (2009) The paper provides an analysis of the antecedents and barriers for reverse

capability transfer in multinational corporations. Subsidiary autonomy,

environmental heterogeneity and managerial initiatives are all necessary

antecedents of unique capability development at the subsidiary level.

Person-to-person communication is also required for intra-MNC capability

transfer in any direction.

Szulanski et al. (2004) The paper explores the conditions as to when and how a recipient’s

perception of the trustworthiness of a source affects the effectiveness of the

transfer of organisational practices.

Page 57: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

55

Author Description

Tsai (2002) The paper studies the effectiveness of coordination mechanisms on

knowledge sharing in intra-organisational networks that comprise both

collaborative and competitive ties among organisational units.

van Wijk et al. (2008) The paper discusses antecedents and consequences that impact

organisational knowledge transfer and the relationship between knowledge

transfer and its consequences.

In this research, the researcher mainly focuses on knowledge transfer between

organisations (buyer and supplier firm) in the context of collaborative product

development. However, this research considers knowledge within the buyer and

supplier side because the transfer over the organisational interfaces originated

from knowledge transfer within the firm.

2.3.4 Factors influencing knowledge transfer

This section discusses the factors influencing knowledge transfer. As mentioned

previously, knowledge transfer may be viewed as taking place between two

parties: the source and the recipient within a firm or across organisations. It

includes two basic processes: sending knowledge and receiving knowledge.

According to Chapter 2.3.3, any conceptualisation of knowledge transfer would

include the participants (source and recipient), the information or knowledge to be

transferred (message) and the context or environment. Based on this, the

influential factors can be summarised into four main areas: the characteristics of

the source and recipient, the characteristics of the knowledge being transferred,

the transfer mechanism and the characteristics of the context or environment.

Characteristics of the source and recipient

Many studies state that absorptive capacity, prior experience, motivation and trust

are the key factors that affect knowledge transfer (e.g. Abino et al. 1999; Argote

& Ingram 2000; Bou-Llusar & Segarra-Cipres 2006; Easterby-Smith et al. 2008;

Gupta & Govindarajam 2000; Li-ping 2006; Minbaeva 2007; Szulanski 2003;

Timbrell et al. 2001; Xu & Ma 2008).

Absorptive capacity is one of the most cited factors influencing knowledge

transfer. It is defined as the ability to recognise the value of new knowledge and

to assimilate and use that knowledge (Cohen & Levinthal 1990). The source

needs absorptive capacity to appreciate the potential value of sending knowledge

Page 58: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

56

to the recipient. At the same time, the recipient needs absorptive capacity to

understand, assimilate and utilise the knowledge. Absorptive capacity is

influenced by prior knowledge and experience of the source and the recipient

(Cohen & Levinthal 1990). Sources and recipients who lack such prior experience

or knowledge will be less likely to recognise the value of the new knowledge, and

will be unable to integrate it with their own knowledge or apply it for a purpose.

In addition, the motivation of the source and the recipient is critical to knowledge

transfer. Lack of motivation may lead to the source being unwilling to transfer

knowledge, and the recipient being reluctant to accept such knowledge from the

source. The reasons that the source and the recipient are unwilling to transfer

knowledge may come from a lack of trust between the two parties. Trust is very

important in facilitating knowledge transfer (e.g. Chen et al. 2006; Jiaxi 2009;

Lam & Chin 2005; Lee et al. 2008). Without creating a climate of trust between

the two parties, firms cannot gain entrance to take advantage of the partner’s

knowledge.

Characteristics of the knowledge being transferred

The characteristics of the knowledge being transferred are about how easy it is to

transfer to others (Bou-Llusar & Segarra-Cipres 2006; Heiman & Nickson 2002).

Generally, knowledge is created from different sources and associated with

different degrees of ease of transfer. Knowledge transferability is about how much

the knowledge depends on the context in which it is presented and how much

meaning would be lost if some or the entire context was removed (Novins &

Armstrong 1997). Transferability relates to tacit and explicit knowledge. High

tacit knowledge is more difficult to transfer than explicit knowledge because it is

embedded in individual cognition within a specific context (Blumenberg et al.

2009; Szulanki 1996; Xu & Ma 2008).

The transfer mechanism

There are many mechanisms that exist for transferring knowledge from one firm

to another for example, documents, project reports, face-to-face meetings,

telephone calls, e-mails, video conferences or personal transfer (e.g. Almeida &

Grant 1998; Kess et al. 2007; Smed et al. 2001). The important aspect for

transferring knowledge is to choose a suitable method of knowledge transfer for

the different types of knowledge being transferred (Argote 1999; Dixon 2000;

Page 59: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

57

Martin & Antonio 2010). Explicit knowledge can be transferred through, for

example books, documents, databases and meetings. On the other hand, tacit

knowledge can be transferred through personal interactions, meetings, training

and learning by doing.

Characteristics of the context or environment

Many studies have found that organisational context – regarding the formal

structure and systems, sources of coordination and expertise, behaviour norms

and culture in the organisation – affects the knowledge transfer (e.g. Sun & Scott

2005; Szulanski 2003). In addition, the relationship between the source and the

recipient is one of the most important factors that influence knowledge transfer

(Davenport & Prusak 2000; Easterby-Smith et al. 2008; Giannakis 2008). Social

interaction ties have positive effects for resource exchanges between

organisations (Mirani 2006; Sarker et al. 2005; Tsai & Ghoshal 1998). The

closeness between the companies makes it possible for the employees of the

companies to communicate with each other for various purposes; for example,

sharing experiences, emotions and feelings – through meetings and face-to-face

contacts, etcetera. No matter what kinds and purposes of communication the

employees of the companies engage in, it develops the relationship between

people and consequently leads to the knowledge and experience transfer (Kraatz

1998).

2.4 Social network (SN) theory

In this research, the social network theory is employed in order to study

individuals’ interaction patterns among buyers and suppliers whilst transferring

knowledge in the product development process.

2.4.1 The social network analysis (SNA) concept

Social network analysis (SNA), which is becoming increasingly popular as a

method for understanding complex patterns of interaction, is a useful tool to

analyse patterns of relationships among people in groups and also to analyse the

structure of these patterns and discover what their effects are on people and

organisations (Anklam 2005; Scott 1999; Wasserman & Faust 1997). Social

network theory focuses on social relationships among a set of actors. It focuses on

Page 60: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

58

the relationships within the network more than their attributes of individuals. The

relationships are viewed in terms of nodes and relational ties. Nodes are the

individual actors within the network. The actors may also be groups,

organisations or nations. These actors are linked to one another by relational ties

(Wasserman & Faust 1997). From a network perspective, the actions of actors in

different ways can be explained by knowing the positions or location of actors

corresponding to others in various networks of relationships (Gulati et al. 2000).

In the context of collaborative product development, Croom (2001) states that

effective collaboration is dependent on the management of relationships between

buyers and suppliers. Thus, in this dissertation, the concept of social network

plays a role in examining the buyer-supplier relationships while transferring

knowledge in collaborative product development.

The concept of social network analysis has been examined under two

properties: relational properties and structural properties (Streeter & Gillespie

1992). Relational properties focus on the content of the relationship between

network members and on the form of these relationships. The aspects of relational

properties have been studied according to what flows or what is exchanged in

networks by focusing on the four basic types of exchange content: resources,

information, influence and social support (Streeter & Gillespie 1992). Another

aspect of relational properties is the nature of the relationship, which refers to the

qualities of the relationship between members in the network. Structural

properties, on the other hand, describe the structural characteristics, which can be

divided into three levels of analysis: individual members, subgroups and total

networks (Streeter & Gillespie 1992).

The main goals of SNA are to understand and visualise relationships among

people in groups, to study the factors that influence relationships and to uncover

the correlations between relationships, and to improve, for example

communication, workflow, collaboration and knowledge flow in an organisation

(Allard 1996). Borgatti and Molina (2003) described SNA as a systematic

approach to make the invisible flows seem more visible and to make the

intangible become tangible. SNA uncovers the patterns of people’s

interconnectedness and interactions. The analysis can produce understanding as

well as action. The success or failure of organisations, societies or any type of

collaborations may depend on these patterns. Therefore, SNA is a very powerful

approach for measuring relationships and flows between people, groups,

organisations or other entities.

Page 61: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

59

SNA represents networks as graphs. Graph theory is used to define

fundamental concepts in SNA. Relationships between nodes can be translated to

matrices and then a set of measures can be calculated using those matrices. SNA

measures many structural characteristics of the network, like the existence of

subgroups, the relative importance of individual actors and the strength of the

links (Wasserman & Faust 1997). A number of software tools, such as NetMiner,

UCINET and NetDraw, have been developed to aid the analysis and provide the

visualisation of the networks.

2.4.2 Types of individuals in the network

Information collected from social network surveys can be used to create network

diagrams that depict the relationships between members of the network and help

to identify the characteristics of people in the network (Cross & Parker 2004;

Mueller-Prothmann & Finke 2004). Cross and Parker (2004) classified people in

the network into four main types. The first type is central connectors, who have

the most connections in the network. Most information in the network flows

through this person. This means that most people in the network rely on this

person for information. Whether or not the central connector’s impact is positive

or negative cannot be stated. If the group is overly dependent on this person, he or

she may be a bottleneck, slowing the flow of information and holding up

decisions. On the other hand, the central connector often plays a very positive role,

providing valuable information and holding a group together. The second type is

boundary spanners who provide links between two groups of people that are

separated by physical location, hierarchical level or positions/roles. This kind of

person plays an important role when people need to share different kinds of

expertise. The next type is information brokers who communicate information

across subgroups. These people can help organisations transfer certain kinds of

information and promote connectivity throughout a network. The final type is

peripheral people who lack skills, expertise and sociability for the job. Therefore,

these people may represent under-utilised resources.

In addition to this classification, Mueller-Prothmann and Finke (2004)

described another classification. They classified people in the network into three

types: expert networkers, experts and agents, silent experts and experts of highly

specialised knowledge. Expert networkers are considered as having high levels of

expertise because they have the most connections in the network. Experts and

agents are considered as experts; nonetheless, they have the most connections.

Page 62: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

60

Typically, experts and agents hold a management level position, such as head of

department. Silent experts are considered as the potential resources of the network

that are not used. Their skills or expert knowledge are not transferred throughout

the network or organisation. Finally, experts of highly specialised knowledge are

those who have a relationship across formal hierarchies in the organisation. This

relationship may indicate the highly specialised expertise of these people.

2.5 Requirements engineering (RE)

Requirements engineering (RE) is a systematic and iterative process to understand,

capture and document what stakeholders (e.g. customers, users, developers,

businesses) require from a product or a system into written form requirements and

specifications (e.g. Asghar & Umar 2010; Kauppinen et al. 2004; Kotonya &

Sommerville 1998; Sommerville 2006; Wiegers 2003). The purpose of RE is to

serve all stakeholders’ needs in a product or a system and create understandable,

complete, and consistent requirements and specifications that can be accepted by

all stakeholders in order to use those as an input in producing a product or a

system (Asghar & Umar 2010; Pfleeger 1998; Pohl 2010). Requirements act as a

map telling people in the development project how to work in the coming

processes until the end. Effectively organising the RE process plays a significant

role in a product’s success since the quality of execution of the RE process

directly impacts the quality of requirements. If the requirement is not well-defined

– e.g. incomplete, inconsistency and ambiguous-, it is difficult to make a

successful project no matter what how well the rest of the development process

was done (Beichter et al. 1984; Grady 1993; Leffingwell & Widrig 2000;

Sommerville 2006).

2.5.1 The requirements engineering process

Requirements engineering (RE) originates from the development of the software

requirements engineering method (Alford 1997). The term ‘engineering’ refers to

techniques that are systematic and repeatable. These techniques are used to ensure

that requirements are clear, concise, consistent and valid (Kotonya &

Sommerville 1998). RE is a vital contributor to the overall quality of products and

successful product development. According to the previous studies, the factors

causing failures in product development projects were related to the RE practices

(Glass 1998; Jiang 2005).

Page 63: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

61

RE is a core process for product development concerned with understanding

stakeholders’ needs, identifying what the company intends to build and ensuring

product development builds a product that satisfies those requirements at

minimum cost and time (Asghar & Umar 2010; Kauppinen et al. 2004). Many

stakeholders are involved in the RE process, including users, engineers and

developers. They participate in requirements and cooperate with each other. RE is

divided into development and management. According to Pohl (1996), the RE

process is viewed as an iterative process for defining the requirements to be

developed in product development process and can be divided into three

dimensions: a specification, agreement and representation. The specification

dimension aims to understand all the requirements proposed. This dimension is

necessary to make any vague requirements clearer, complete and understandable

requirements. The agreement dimension tries to make agreed requirements and

solves the conflicts of each stakeholder’s view. Since the requirements come from

different stakeholders who have different perspectives, conflicts can take place.

The representation dimension copes with documenting and specifying the

requirements by using the appropriate format.

However, the RE process is very crucial and the most difficult process of

product development (Brooks 1986). The customers or users often cannot explain

exactly what they really want. Therefore this process needs very cooperative

between users and developers to find the answer that what the system should be

(Brooks 1986).

Typically, requirements engineering is divided into development and

management (Figure 9). Figure 9 illustrates the requirements engineering process

which is originally discussed by Hooks and Farry (2001), Kotonya and

Sommerville (1998), Leffingwell and Widrig (2000), Parviainen et al. (2003),

Sommerville (2006) and Wiegers (2003).

Page 64: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

62

Fig. 9. The requirements engineering process.

1) Requirements development deals with discovering, analysing and documenting

requirements (e.g. Leffingwell & Widrig 2000; Sommerville 2006; Wiegers 2003).

The purpose of the output of requirements development is the product

requirements documents. Requirements development can be further divided into

elicitation, analysis, documentation and validation processes. These processes are

interwoven, and there is a great deal of iteration and feedback from one process to

another.

1.1) Elicitation is the process of discovering and identifying requirements by

communicating with stakeholders who will be affected by the system and who

have a direct or indirect influence on the requirements. The goal of this process is

to make what users want in a product in a way that stakeholders can understand

(Pohl 2010). The crucial activity in this process is to identify the relevant

requirements sources. They could be, for example existing documents, current

organisation and systems, needs of stakeholders (Robertson & Robertson 2006).

There are many techniques are used to elicit the requirements: questionnaire

surveys, workshops, scenario-based techniques, interviews, brainstorming,

etcetera (e.g. Leffingwell & Widrig 2000; Pohl 2010; Sommerville 2006). These

techniques are very helpful to describe what stakeholder want or need since users

always cannot explain exactly what they want and developers cannot understand

what user’s concern. Users and developers always explain by using words or

assumptions which others may not be familiar or understand (Pohl 2010). The

results of this situation are misunderstanding between stakeholders and

Requirements Engineering Process

Requirements development Requirements management

InputStakeholders’

needs

Process

Elicitation Analysis Documentation Validation

OutputAgreed

requirements

Requirements management

planning

Identification, Traceability, Change management

Page 65: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

63

incomplete specifications (Pfleeger 1998). Therefore the communication between

stakeholders to discover the requirements is very important in this process

(Pfleeger 1998; Pohl 2010).

1.2) Analysis is the process of analysing the initial set of requirements and

negotiating among different stakeholders to decide which requirements to accept

since conflicts, overlaps, omissions and inconsistencies will inevitably arise,

which have to be resolved. The goal of this process is to make an agreement on

the requirements which are elicited from the various stakeholders involved in the

process (Pohl 2010). To achieve this goal two tasks need to be handled: the

conflicts between stakeholder’s viewpoints have to be found and these conflicts

have to be resolved. Furthermore, it is necessarily to bring the right people to

participate in the process since in this process involved people must communicate

and exchange their different viewpoints and must negotiate and make decisions

about the requirements that can be acceptable to everybody (e.g. Macaulay 1996;

Pfleeger 1998; Sommerville 2006).

1.3) Documentation is the process of documenting requirements in a standard

requirements document in order to enable communication. The requirements must

be also documented in a way that they can be tracked throughout the development

process. There are two types of requirements documentations (Pfleeger 1998).

1) The requirements definition document which is written in the customer’s terms

describes what the customer truly wants or expects in a product. 2) The

requirements specification document which is written by requirements analysts

for the development of a product design. Customers can understand the

requirements definition document but may difficult to understand the

specification whereas the designer and developer can create a design from the

requirements specification document.

1.4) Validation is the final process of requirements development. This process

aims at checking that the requirements specification accurately represent or meet

the customer needs or intentions and are consistent, complete and correct with the

requirements definitions (Pfleeger 1998). Therefore this process concerns the

traceability between the definition document and specification. Each specification

must be traced to a requirement in the definition document and each requirement

in the definition document must be traced to the specification. In addition to this,

the validation must be checked by ensuring that the goals and intentions of the

Page 66: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

64

stakeholders are really met (Pfleeger 1998). Many of requirements validation

techniques are used: interviews, reviews, checklists, scenarios, mathematical

proofs, automated models to enact functions and prototypes (Pfleeger 1998).

These processes in requirements development are supported throughout by

requirements management. Managing requirements is a parallel process for other

requirements engineering processes (Kotonya & Sommerville 1998; Sommerville

& Sawyer 1997). Even when requirements are specified, it is likely that they will

be changed at least once during development and they can be changed

immediately after development. Therefore, requirements must be managed

throughout the product development process. Managing requirements helps

ensure that iterative and unanticipated changes are maintained throughout the

development process.

2) Requirements management, on the other hand, aims to manage changes

concerned with organising, tracking and maintaining requirements throughout the

development process. Requirements management consists of four main activities:

requirements identification, requirements traceability, requirements change

management and requirements management planning (Parviainen et al. 2003).

Requirements identification relates to the identification and storage of

requirements items. Requirements traceability concerns the ability to describe and

follow the requirements through a product’s life. Requirements change

management involves a large amount of information, which is transferred from

people to people and change related information is collected during the process

(Leffingwell & Widrig 2000; Kotonya & Sommerville 1998; Hooks & Farry

2001). This activity aims to manage changes to the requirements to ensure that

information is collected for each proposed change and transferred to the correct

people at the right time. Requirements management planning defines goals and

procedures for requirements management. It deals with planning and

documentation of identifications, traceability and change management activities.

Challenges related to requirements engineering

The RE process is a communication activity not technical activity (Wiegers 2003).

It involves frequent communication with stakeholders who have different

backgrounds, skills, knowledge, perspectives and goals (Coughlan & Macredie,

2002). During this process, stakeholders need to work collaboratively to

communicate and transfer knowledge to express their needs, wants, information

or knowledge for creating complete and accurate requirements. However,

Page 67: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

65

communicating and transferring during the RE process are not an easy practice

since this process not only involve with various groups of people but also wants,

requirements or knowledge to be communicated and transferred are difficult to

express explicitly to others (Pilat & Kaindl 2011) because they are mostly tacit

and intangible (Medeni et al. 2011). The challenges of communication and

transfer among stakeholders can have various causes (Damian 2007; McAllister

2006; Naz & Khokhar 2009), for example the ability to communicate

requirements, the ability to understand what others communicate to and the

differences in the stakeholders’ knowledge and skill level (Kauppinen 2005; Nair

2009). In addition, the communication channel is also the important challenge.

Communication through only an electronic channel such as email, telephone and

video conference is not enough and effective. Face-to-face communication is still

needed. Thus, having the sufficient and suitable channel to communicate and

transfer could ease the problem.

A limited time frame could also be a crucial challenge when developing

requirements (Alves et al. 2007; Nair 2009). Since developers need to run on tight

schedules, this can lead them to make many mistakes. Additionally, there are

other challenges in developing requirements including lack of technical skills,

lack of understanding of the software and the product line being worked and lack

of a writing requirement skill (e.g. Alves et al. 2007; Kauppinen 2005; McAllister

2006). Such challenges lead the company fail to capture, translate and document

requirements correctly and the results from this failure are ambiguity and

incompletion of requirements that affects the success of product development (e.g.

Lubars et al. 1993; Raatikainen et al. 2011; Wiegers 2003; Zagajsek et al. 2007).

2.5.2 Requirements

Requirements are not the design, but what needs to be done. They are identified

during the early stages of product development as a specification of what should

be built. Many researchers have given a definition of requirements. Lawrence

(1997) suggests that a requirement is “anything that drives design choices.”

Webster’s Ninth New Collegiate Dictionary (1989) defines a requirement as

“something required; something wanted or needed.” Kotonya and Sommerville

(1998) define a requirement as “a statement of a system service or constraint.”

Requirements are important in developing a product because they are descriptions

of what the system must do, they provide a reliable way for the stakeholders to

agree, and they afford a framework for designing, implementing and testing. They

Page 68: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

66

emerge from the conversations among stakeholders including for example,

designers, engineers, product managers, suppliers and customers.

Requirements express the means how knowledge is transferred in the RE

process. Different requirements are important in knowledge transfer as knowledge

is embodied in the requirements and in communicating them.

There are numerous types of requirements (see Table 9), but the most cited

requirements types can be divided into: functional requirements, non-functional

requirements and constraints (Brackett 1990; Robertson & Robertson 2006;

Sommerville & Sawyer 1997). Functional requirements represent something that

the system must be able to do. Non-functional requirements specify something

about the system itself and how well it performs its functions concerned with

usability, availability, reliability, supportability, testability and maintainability

(Kitchenham & Pfleeger 1996; Sommerville & Sawyer 1997). Constraints are

conditions that exist because of limitations imposed by internal and external

factors. Some categorisations of requirements relate to technical management.

The Defense Acquisition University (2001) classified requirements into: customer

requirements, functional requirements, performance requirements, design

requirements, derived requirements and allocated requirements. Sommerville

(2006) introduces requirements types that include mutable requirements,

emergent requirements, consequential requirements and compatibility

requirements. Some researchers classified requirements as related to business and

technical aspects (Grady 1993; Stevens et al. 1998; Westfall 2006; Wiegers 2003).

Such classification consists of common requirements (including business

requirements) that describe what must be fulfilled to provide value, user

requirements that refer to quality attributes, product requirements that explain

attributes of a system or product, and process requirements that specify

methodologies to be followed and constraints that organisations must consider.

According to the variety of requirements classifications, there is no general

agreement on how to classify requirements. It depends on the implementation

objectives and characteristics of each business or company.

Page 69: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Ta

ble

9. L

ist

of

req

uir

em

en

ts c

las

sif

ica

tio

ns

.

Cla

ssifi

catio

n o

f R

equirem

ents

A

uth

or(

s)

Funct

ional

req

uire

me

nts

Non-f

unct

ional

req

uire

me

nts

So

mm

erv

ille

& S

aw

yer

(19

97

)

Funct

ional

req

uire

me

nts

Non-f

unct

ional

req

uire

me

nts

Co

nst

rain

t

Bra

cke

tt (

19

99

); K

au

pp

ine

n

(20

05

); R

ob

ert

son

& R

ob

ert

son

(20

06

)

En

d-u

ser

req

uire

me

nts

R

eg

ula

tory

req

uire

me

nts

Co

rpo

rate

req

uire

me

nts

Tech

nic

al

req

uire

me

nts

Ge

rsh

en

son

& S

tauff

er

(19

95

),

Mo

rris

& S

tau

ffe

r (1

99

4)

Mu

tab

le r

eq

uire

me

nts

E

me

rge

nt

req

uire

me

nts

Conse

que

ntia

l

req

uire

me

nts

Com

patib

ility

req

uire

me

nts

So

mm

erv

ille

(2

00

6)

Use

r need

F

eatu

re

Funct

ion

A

ttribute

D

avi

s (1

99

3)

Funct

ion

P

ropert

ies

Const

rain

t

Ab

bo

tt (

19

86

)

Busi

ness

requirem

ents

U

ser

requirem

ents

S

yste

m r

equirem

ents

S

teve

ns

et

al.

(19

98

)

Busi

ness

requirem

ents

U

ser

requirem

ents

F

unct

ional r

equ

irem

ents

W

iegers

(200

3)

So

ftw

are

ne

ed

s C

ust

om

er/

use

r-

oriente

d

req

uire

me

nts

Deve

lop

er-

oriente

d

req

uire

me

nts

R

om

bach

(199

0)

Sta

keh

old

er

ne

ed

s F

ea

ture

s S

oft

wa

re

req

uire

me

nts

Leffin

gw

ell

& W

idri

g (

2000)

Hard

ware

require

ments

(pe

rfo

rma

nce

req

uire

me

nts

or

const

rain

ts)

So

ftw

are

requirem

ents

(funct

ional o

r non-

funct

ional

requirem

ents

)

Gra

dy

(19

93

)

67

Page 70: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Cla

ssifi

catio

n o

f R

equirem

ents

A

uth

or(

s)

Deve

lopm

ent

req

uire

me

nts

Pro

du

ct

req

uire

me

nts

Pro

cess

req

uire

me

nts

G

rad

y (1

99

3)

Input/outp

ut

req

uire

me

nts

Tech

nolo

gy

and

syst

em

-wid

e

req

uire

me

nts

Tra

de

-off

req

uire

me

nts

Sys

tem

te

st

req

uire

me

nts

Bu

ed

e (

19

97

)

Mandato

ry

req

uire

me

nts

Pre

fere

nce

req

uire

me

nts

Ba

hill

& D

ea

n (

19

99

)

Funct

ional

req

uire

me

nts

Pe

rfo

rma

nce

req

uire

me

nts

Cust

om

er

req

uire

me

nts

Desi

gn

req

uire

me

nts

Derive

d

req

uire

me

nts

Allo

cate

d

req

uire

me

nts

Defe

nse

Acq

uis

itio

n U

niv

ers

ity

(20

01

)

Busi

ness

requirem

ents

U

ser

requirem

ents

(busi

ness

rule

s,

qualit

y attrib

ute

s)

Pro

duct

requirem

ents

(fu

nct

iona

l, no

n-f

unct

ional,

ext

ern

al

inte

rface

, data

an

d c

onst

rain

ts r

equ

irem

ents

)

W

est

fall

(2006)

68

Page 71: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

69

The characteristics of good requirements are variously stated by numerous

researchers (Firesmith 2003; Sommerville 2006; Wiegers 2003). However, the

general characteristics of good requirements can be summarised as consisting of

one statement each, one possible interpretation for each, traceable to a stakeholder,

feasible, testable/verifiable, clear and they should actually be required. Good

requirements result in the product being completed according to the stakeholders.

Bad requirements, on the other hand, lead to the product not attaining its desired

goal, missing important functionality and triggering disagreements about

interpretations.

In conclusion, RE is the process to transform the stakeholders’ needs into a

complete and consistent specification which is an input to the design and

development phase. According to the previously mentioned, it is clearly that RE is

the toughest and complex process in product development since this process is

involved by the number and diversity of people (Brooks 1986). There are multiple

stakeholder groups involved in the RE process including for example, customer,

designer, developer, and requirements analyst (Mottonen et al. 2009). Anyone can

act as a stakeholder who expresses want and need in a product or system.

However, the requirements are created mainly based on customer needs and

wants. The customers know what they want but do not know how to design or

develop. The designers know how to design a product but do not know the tools

and techniques required to create and maintain a product or system. The

developers understand how to create a product or system and know the

technologies or tools for using in producing. The requirements analyst is the

person who documents the requirements. The requirements analyst needs to write

a requirement that is understandable, unambiguous, consistent, and complete to

the developer. (Fox 1982). The communication could be a main problem of the

RE process because there is a lot of information and knowledge has to be

transferred and shared among these people (e.g. Bubenko 1995; Damain 2007;

Naz & Khokhar 2009). Communication challenges will accumulate when

knowledge transfer occurs over organisational interfaces (Kropsu-Vehkapera et al.

2011). However, successful RE not only depends on managing the

communication and knowledge transfer among stakeholders, identifying the right

person to participate in the process and organising the stakeholders who have the

difference background and perspective but also managing the changes which

could be happened all the time.

Page 72: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

70

2.6 Theoretical synthesis

The theoretical study provides a foundation for studying collaborative product

development and highlights the relations among the key concepts in this research

(see Figure 10). Collaboration in product development will affect the

development and production process because, during that period, there will be a

high rate of communication concerning the information, knowledge and ideas of

the product. The communication is at a peak; especially, in the beginning phase of

the product development process. This period is the time for collecting

information about the needs and requirements of the stakeholders. After that, the

needs and requirements collected will be developed as the final product or service.

Knowledge transfer between the relevant parts throughout the whole process of

the product development is extremely important, especially in the requirements

engineering process. Any requirements developed can be considered as the input

of the product development in all subsequent processes. The completion of the

requirements will even affect the success or failure of the project.

However, the literature study shows that knowledge transfer requires many

factors such as trustworthiness, relationships, the transferring channel or the

context, which can all support or reduce the transfer flow. The difficulty in the

transfer will be more obvious in cases where the product development is done

with an external firm. Moreover, when the knowledge to be transferred is in the

form of tacit knowledge it is more difficult than explicit knowledge, because tacit

knowledge typically takes place in a social context or cannot be excluded from

social context. Additionally, the literature review shows that good interaction

between relevant people can enhance the efficiency of the knowledge transfer and

interpersonal interaction is considered crucial in the knowledge transfer process.

Therefore, in addition to the theory of collaborative product development,

knowledge transfer and requirements engineering, the theory of social network is

another critical theory to be analysed in this research. It can help us see the

relationship patterns between people during the knowledge transfer process. The

literature and the previous studies suggest applying social network theory in order

to gain an understanding about the individual interactions. The interactions

between people can be studied by using social network analysis (SNA) as a tool.

Page 73: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

Fig

. 10

. T

he

lin

kag

e o

f k

ey

co

nc

ep

ts o

f th

is d

iss

ert

ati

on

.

71

Page 74: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

72

Challenges of knowledge transfer in the requirements engineering process relate

to three main elements: people, process and context. These elements originate

from the nature of transfer which comprises a source and recipient (people), a

message and channel (process) and a context. The common understanding

between people is the critical challenge in collaborative work. This challenge may

cause from, for example the ability/ skill of people and trust between people.

These challenges directly impact transfer performance and requirements to be

created. Also, types of knowledge and transfer channels could create transfer

difficulty. Context or environment could lessen or severe the challenges. To

overcome these challenges, it is necessarily to use a potential solution to manage

people, process and context as a key challenge of transferring knowledge in

collaborative work.

In conclusion, the study of the concept of product development, buyer-

supplier relationships, collaboration in product development and the requirements

engineering process lead to the understanding of what the challenges between

suppliers and buyers in product development are. The exploration of the concept

of knowledge transfer can indicate how the knowledge is transferred, and what

the components and relevant factors affecting the efficiency of the process are.

Alongside this, the study of the concept of social network – in terms of actors,

relational ties and network structure – will show the individual interaction

patterns during knowledge transfer in collaborative product development.

Page 75: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

73

3 Research contribution

This chapter presents the individual research contributions of the research papers.

The research questions are presented in the introduction chapter and the results

synthesis is combined in Chapter 3.6.

3.1 Challenges of CPD

The collaboration with the supplier becomes a key strategy for product

development. The collaborative product development with the supplier leads not

only to reducing the risks, costs and development time, but also sharing resources

and capabilities and accessing new knowledge, skills and experiences that the

company does not have. Nevertheless, collaborative product development is

facing increasing challenges, since it involves collaborating with suppliers who

have different structures, cultures, knowledge, skills and expertise. The results of

this paper indicate that high-tech companies face numerous challenges in CPD

(Table 10). These challenges can be categorised into seven groups: contract

management, information management, collaboration management, resource

management, NPD management, technology management and globalisation

management.

Table 10. Challenges of CPD.

Classification List of Challenges

Contact management 1 Negotiation strategies

2 Managing the win-win situation (combination of competition and

collaboration)

3 Degree of supplier integration

Information management 4 Understanding the dynamics of information between network partners

5 Managing the transferred and shared information between network

partners

6 Managing communication between partners

Collaboration management 7 Mutual trust

8 Mutual goal

9 Lack of commitment

10 Understanding the role of competence flow between supplier and buyer

11 Increased communication and coordination costs

12 Managing the cross-functional interface

Resource management 13 Pressures of continuous quality improvement and cost reduction

Page 76: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

74

Classification List of Challenges

NPD management 14 Generating new ideas

15 Rapid pace of new product introduction

16 Finding a superior product

17 Finding the best partner candidate for R&D

18 Increased expectations of quality and reliability

Technology management 19 The features of technology (technological change, complexity and

uncertainty)

20 Increased special know-how of some technology

21 Finding the best technological solution

Globalisation management 22 Need for cultural understanding

23 Increased competitive forces

Contract management

Contract management is somehow relative to supplier selection, degree of

supplier integration, contract negotiations and project group’s cooperation and

coordination of subcontractor’s work management. The types of contracts

between the case company and partner depend on each case. Sometimes it is just

in licensing; at other times it is a more integrated collaboration. The important

thing is to define the right level for each case. However, the case company tries to

make long-term contracts with partners in order to give stability and create good

relationships for collaboration.

Information management

The transfer of information between the case company and the partner is one of

the key issues in CPD. The information is transferred and shared through many

channels, such as meetings, teleconferences, e-mails and face-to-face discussions.

However, this issue is challenging because the case company has to balance

between trust and openness regarding what and how much is shared and

transferred between the case company and the partner.

Collaboration management

The important issue in this category is to manage a group of people with different

backgrounds and expertise to achieve a common goal. Additionally, the balance

Page 77: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

75

between being fair to the partners and taking the business into account is also a

key challenge.

Resource management

The challenge of resource management in the case company is to get enough

resources or competence from the supplier.

NPD management

NPD management is also one of the key challenges of CPD. The achievement of

product development not only depends on the capability of the case company, but

it also relies on the capability of the supplier. In the case company, the crucial

issues are how to collect and put new ideas into practice, together with monitoring

and evaluating those ideas and selecting a suitable supplier for joint development.

Technology management

Besides the complexity of technology, technological change and unpredictability

also create difficulties and barriers that have to be managed.

Globalisation management

Cultural differences and competitive forces are issues that create barriers to CPD.

The differences between cultures are as significant and complex as they are

difficult to understand and use in a thoughtful way. Cultural learning helps

companies understand the way partners generally act and recognise that the role

expectations and other social variables (such as ethnicity and place of residence)

affect the way partners speak and behave. Additionally, increased competitive

forces are another challenge that the company must be aware of. Every company

has to deal with the same challenges in the field sooner or later; therefore, it is not

only one company that has to deal with the competitive forces.

According to the results of this paper, the most significant challenges for

CPD are mutual trust, generating new ideas, finding a superior product and

finding the best partner candidate for R&D. The majority of these challenges are

somehow related to the collaboration and product development management.

Supplier collaboration requires a high level of trust for the success of the

Page 78: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

76

development of which the benefits can be shared. Supplier partnering needs to

take the participants into the product lifecycle as soon as possible, so that both

suppliers and buyers can provide the information and knowledge input for the

development process, which are crucial sources for generating new ideas.

3.2 Knowledge transfer pattern in CPD

The results of this paper provide a framework for analysing knowledge transfer in

CPD (Figure 11) and the pattern of knowledge transfer between buyers and

suppliers in CPD (Table 11). According to the framework, knowledge transfer

patterns can be analysed based on three dimensions: types of transferred

knowledge, transfer methods and the frequency of knowledge transfers.

Fig. 11. A framework to analyse knowledge transfer in CPD (Distanont et al. 2012

published by permission of Inderscience).

Types of transferred knowledge

Transferred methods

Transferred frequency

CPD

CPD

Tacit

Explicit

Managerial Engineering

Page 79: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

77

Types of transferred knowledge

Transferred knowledge in CPD can be classified into four types: namely, explicit

engineering knowledge, tacit engineering knowledge, explicit managerial

knowledge and tacit managerial knowledge. Managerial knowledge is defined as

the skills and techniques for managing and organising design and development in

the collaborative product development process. Engineering knowledge is defined

as a body of knowledge, understandings and practices that relate to product

design and development in the collaborative product development process.

Managerial and engineering knowledge can be either explicit or tacit.

Transfer methods

Each type of this transferred knowledge can be transferred through 11 methods:

shared documentation, data and/or instructions; social media; expert interviews;

visits to the supplier’s location; constant electronic communication through

telephone/e-mail; informal communication (face-to-face communication); joint

meetings; contact persons; design review meetings; staff exchanges;

teleconferences. The types of transferred knowledge are relative to the transfer

methods. Different transfer methods have different capacities for transferring

types of knowledge. In addition, each method of knowledge transfer has different

levels of efficiency.

The frequency of knowledge transfers

The frequency of transfer depends on the transfer’s role at the different phases of

product development. The different transfer methods are used for different types

of knowledge transfer and different phases of product development. Some

methods are used more widely and more often than other methods in different

phases of product development. Explicit knowledge is transferred more frequently

than tacit knowledge in the early phase of development. In the later phase, tacit

knowledge would be more frequent. Additionally, some transfer methods have a

very important role in some phases of product development, but not in others. For

example, joint meetings and visiting suppliers play a key role in the early phase of

development, but in the other phases design review meetings, teleconferences,

expert interviews and social media become important methods of transfer.

Page 80: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

78

Table 11. A pattern of knowledge transfer in CPD.

Transfer pattern Tacit managrial

knowledge

Tacit engineering

knowledge

Explicit managerial

knowledge

Explicit engineering

knowledge

Typical example 1.Material

management

2.Time management

3.Customer/marketing

management

1.Product design

knowledge

2.Testing

knowledge

3.Problem solving

experiences

4.Development

skills and

techniques

1.Meeting

document

2.Marketing

information

3.Quality document

4.Feedback report

5.Development

policy

1.Product and

design document

2.Instructions

3. Feedback report

Methods for

transfer

1.Face-to-face

communication

2.Telephone/ e-mail

3.Joint meeting

4.Staff exchange

5.Visit supplier

6.Social media

1.Face-to-face

communication

2.Telephone/ e-mail

3.Joint meeting

4.Staff exchange

5.Visit supplier

6.Teleconference

7.Design review

meetings

8.Contact persons

9.Expert interviews

1.Joint meeting

2.Shared document

3.E-mail

1.Joint meeting

2.Shared document

3.E-mail

4.Design review

meetings

Frequency of

transfer

High frequency of

transfer in the middle

to late phase of the

product development

process

High frequency of

transfer in the

middle to late phase

of the product

development

process

High frequency of

transfer in the early

phase of the

product

development

process

High frequency of

transfer in the early

phase of the

product

development

process

According to the results of this paper, CPD requires a great deal of both explicit

and tacit knowledge in a managerial and engineering context. The variety of

methods for transferring tacit knowledge is wider than for explicit knowledge.

This is because tacit knowledge can be transferred all the time through a variety

of methods – without any limitations in time or place. However, the main

difficulty is the way the new ideas and knowledge are presented for the best

comprehension of the receiver. Transferring explicit knowledge, on the other hand,

involves more limitations in transferring methods, but the receiver could

Page 81: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

79

comprehend the content of the ideas better. Additionally, some transfer methods

have a very important role in some phases of product development, but not in

others. Therefore, knowledge is transferred most effectively when the transfer

process fits the knowledge being transferred. The different transfer methods are

found to have different capacities for transferring types of knowledge.

3.3 Individual interaction pattern in CPD

The results of this paper provide a framework to analyse the interaction pattern

between buyers and suppliers in CPD by using social network analysis (SNA) as

a tool. Figure 12 presents the analysis framework. This framework is used to

describe how the buyers and suppliers worked together to transfer knowledge to

develop a product in practice. It contributes to a better understanding of

collaborative relationships and knowledge flow within CPD.

The framework consists of two aspects: relational and structural properties.

Within the relational properties, two aspects have been studied: transfer content

and potential of a network. Transfer content refers to the transfer of general

knowledge (which is close to explicit knowledge) and problem-solving

knowledge (which is close to tacit knowledge), whereas the potential of a network

refers to the awareness and access dimension. The awareness dimension reflects

the actors’ recognition of the knowledge and valuing what they know and what

another person knows. However, knowing where the knowledge is does not

necessarily imply the ability to communicate. Thus, the access dimension seeks to

identify whether the person who owns the knowledge is accessible and how easy

it is to retrieve. The structural properties can be divided into three levels of

analysis. First, analysis at an individual level describes the interaction among

people within the buyer and the supplier side and this analysis can be used to

identify who is the key person in the network. The second level is subgroups; it

can identify whether there are more linkages or interactions between some

members than others. The last level is the total network; it represents the analysis

of the interaction between suppliers and buyers.

Page 82: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

80

Fig. 12. A framework to analyse the interaction pattern in CPD (Distanont et al. in press

published by permission of IJSR).

According to the results of this paper, the interaction of people while transferring

general knowledge is somehow different than problem-solving knowledge. The

interaction in transferring tacit knowledge is somewhat less frequent than in

transferring explicit knowledge both within a company and over organisation

boundaries. The reason is that most problem-solving knowledge is tacit

knowledge, which can be obtained through experience, skills or the expertise of

an individual. Therefore, this nature of tacit knowledge makes it difficult to

transfer. In the case of general knowledge, it is mostly explicit knowledge, which

can be in the form of documents, manuals and general ideas. They are presumably

easier to transfer. Additionally, the results regarding awareness and accessibility

show that people are familiar with their colleagues’ abilities, but they are not

exploiting the best expertise within people or cannot get a response from others.

This is because of the reluctance of highly expert people and the lack of

trustworthiness among people. However, in order to interact effectively and

enable collaboration, companies need not only to build trust and motivation for

people and create good relationships between people, but also to designate

specific people who really are the central beings (no matter whether they are

specialists, project managers or others) to act as knowledge brokers. Knowledge

brokers are the people who take responsibility in interacting and transferring

knowledge from one team or organisation to another.

CPD

Relationship

Structural properties

Relational properties

Individual Subgroup Total network

Knowledge

Problem-solving

Awareness

Access

Page 83: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

81

3.4 Challenges of KT in the RE process

The results of this paper indicate numerous challenges of knowledge transfer in

the requirements engineering process (Table 12). These challenges can be

categorised as human-oriented factors, process-oriented factors and context-

oriented factors.

Table 12. Challenges of knowledge transfer in requirements engineering.

Classification Challenges of requirements knowledge transfer

Human-oriented factors 1 Skills for defining requests/requirements

2 Skills for understanding and translating requests/requirements

3 Articulating the needs/requirements of potential stakeholders

4 Absorptive capacity of recipient

5 Motivation

6 User-developer interpersonal communications

7 User involvement

8 Trust

9 Experience of management

Process-oriented factors 1 Nature of knowledge to be transferred

2 Transfer channel

3 Transferring requirements information/knowledge

4 Ambiguous requirements

5 Lack of well-defined or standard process

6 Implementation of processes

7 Time constraints

8 Company internal process

Context-oriented factors 1 Executive support/commitment

2 Experience of organisation

According to the results, the majority of challenges relate to the human- and

process-oriented group. The challenges in the human-oriented group can be

clarified as somehow not only related to the ability to interpret, communicate and

understand the knowledge to be transferred, but also to the relationships and trust

between people. The majority of challenges in the process-oriented category are

related to the mechanism of transferring knowledge between people, including the

type of knowledge to be transferred and the transfer channel. Moreover, the

empirical evidence also confirms that the difficulties in requirements transfer may

result from failures in transferring requirements knowledge among stakeholders.

These deficiencies in communicating requirements will weaken the common

understanding. Nevertheless, the interpretations vary and do not always match the

Page 84: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

82

original intentions. Finally, this will cause changes in requirements. According to

the results, it is necessary to have clear and specific inter-organisational

requirements transfer processes to acquire and share the required information and

knowledge during CPD, because knowledge transfer between organisations is

even more complicated than within an organisation and is difficult to employ.

3.5 Organising KT in the RE process

The results of this paper propose means to overcome the challenges of knowledge

transfer in the requirements engineering process (Figure 13). These means act as

managerial actions to overcome the requirements knowledge transfer challenges.

They can be categorised into four main areas: communication, transfer process,

working process and management.

Fig. 13. Means to overcome the challenges (Distanont et al. in press published by

permission of Inderscience).

Page 85: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

83

Communication

Solutions in this group help to solve the communication barriers in order to

communicate efficiently with stakeholders of different backgrounds and over

organisational borders. The aim of these solutions is to create personal

relationships and trust among stakeholders by organising a face-to-face situation.

Good relationships help communication happen easily, smoothly and openly. It

leads to communicating requirements efficiently, especially tacit requirements

that are highly personal and hard to formalise and communicate to others.

Transfer process

Communicating and transferring are very close strategies that support each other.

The goal of effective communication is to transfer and share knowledge. However,

the transferring strategy focuses on improving the transfer process of knowledge

related requirements – both explicit and tacit – between stakeholders. Having a

clear transfer process and using the appropriate transfer methods help to

overcome any transfer difficulties.

Working process

This strategy area aims to improve the working process and define an actual and

common way of working. These solutions lead to the right directions for the right

jobs to save time and minimise costs.

Management

This strategy focuses on building the common understanding between the

management level and the operational level – as well as supporting the

requirements engineering work and coordination and cooperation across

organisations – in order to enhance the quality of the RE process, people and tools

through effective and proper management supports.

In summary, organising knowledge transfer in requirements engineering

process can mobilize not only IT and standard systems but also transfer strategy,

behavior, support staff, and work processes to produce better information and

knowledge transfer and collaborative environments.

Page 86: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

84

3.6 Results synthesis

The ultimate goal of this dissertation is to try to enhance the understanding of

knowledge transfer in requirements engineering in the context of collaborative

product development. In order to understand this better, first of all it is necessary

to understand the current situation of collaborative product development as well

as the challenges influencing this collaboration (Article 1). Then, the knowledge

transfer pattern needs to be understood and clarified (Article 2). Nevertheless, the

success of product development often hinges on ensuring that people are

collaborating effectively in knowledge transfer. Knowing the pattern of

knowledge transfer, the type of knowledge and transfer channels is not enough to

improve collaboration within the process. Therefore, it is necessary to study the

pattern of individual interactions to understand how people behave or should

behave in the knowledge transfer collaborative product development process

(Article 3). Knowing a particular pattern of individual interaction leads to

identifying the effectiveness and efficiency of collaboration. Additionally, the

most crucial phase of product development is the requirements engineering phase.

Effective and efficient requirements engineering is vital for companies to succeed

in product development. The requirements act as a map guiding workers on how

to work in each coming stage until the project is finalised. Without a good map, it

is difficult to successfully reach the destination. Therefore, the study of

knowledge transfer in the requirements engineering process is necessary. In order

to avoid development failure, it is necessary to know what the challenges that

influence knowledge transfer in the requirements engineering process are.

Furthermore, this increases the correct understanding of the requirements

engineering process in the early phase of CPD (Article 4). Finally, the means to

overcome the challenges of knowledge transfer in the requirements engineering

process have been studied (Article 5).

Page 87: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

85

Fig. 14. Research summary.

According to the results of this dissertation, collaborative work for product

development has currently been highly expanded for many reasons; for example,

the severe global competition, increased complexity and difficulty in product

development, the dynamic needs of the customer, the change and uncertainty of

technology, and the change in the structure of the supply chain and high-tech

industry. These factors bring many conditions and challenges to product

development. Companies cannot implement product development in the same

way as they could many years ago. On the contrary, every company needs to seek

collaboration so that any risks that occur can be shared. Also, the expertise

possessed by the other companies can be used to develop the product

appropriately through the process of knowledge transfer. Such a situation

increases the importance of knowledge transfer in the product development

process. A development team might need access to common documents, even

when the teams belong to different organisations, as in collaborative product

development. However, according to the results of this dissertation, driving

collaborative product development and knowledge transfer over enterprise

Page 88: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

86

interfaces smoothly is a truly challenging issue; especially, when the two

companies are not in the same place and when they have different languages and

cultures that can impede the efficiency of knowledge transfer. Additional to this,

the type of knowledge to be transferred – especially tacit knowledge – causes

transfer difficulties, because this kind of knowledge typically takes place in a

social context and requires intense person-to-person communication.

Moreover, transfer problems throughout the product development process can

often be related to the early phases since every stakeholder involved in the project

has some model or image of what the system is and how it will perform. People

need to know what kind of information should be communicated and how to

transfer their vision or idea of the product, so this makes sending the information

and knowledge difficult. Such problems will affect the development time, high

cost and quality of the product. Thus, it is crucial that the product requirements

are complete, unambiguous and consistent early in the development phase and

also correctly understood by all stakeholders. Unclear requirements or poor

quality requirements will not only lead to technical problems later in the product

development, but they may also risk contradictions between the buyer and the

supplier. This may destroy the buyer-supplier relationships. Furthermore, based

on the results, not only are many companies facing challenges in requirements

communication and transfer, but also the requirements are presented differently

no matter where they are from; inside or outside the organisations.

When collaboration in product development between a buyer and a supplier

takes place, there are two processes (the buyer’s process and the supplier’s

process) that need to be combined and synchronised. Therefore, to reduce

complexity and any mistakes and increase the effectiveness of joint development,

there should be some kind of common platform or tool to support the

development process over enterprise interfaces. However, in cases where the

supplier provides just manpower or resources for the buyer, they have to work

strictly within the buyer’s processes. Therefore, this situation is more like an

internal issue without organisational interfaces.

Additionally, the results of this dissertation show that network analysis can

highlight the importance of connections between people, both internally and

externally of the company. The results also demonstrate that people at the

executive level, such as project managers, do not always play a significant role in

inter-firm product development. Also, communication and knowledge transfer

between members of a team is at a lower rate than that between members outside

the team. Such a finding is of considerable interest and needs to be reviewed by

Page 89: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

87

the companies to ascertain the cause, so that appropriate solutions can then be

provided. In addition to concentrating on requirements development and

knowledge transfer in the collaborative product development process, the buyer-

supplier relationships should also be managed from a long-term perspective, in

order to enhance trust between firms. A good relationship between the buyer and

the supplier makes the collaboration go more smoothly and trustworthiness

between them is required for efficient communication and transfer in

collaborative product development, since the degree of uncertainty will always be

rather high. However, a case-by-case study is needed when setting up inter-firm

collaboration.

Fig. 15. Results synthesis.

The results of this dissertation reveal several ideas for implementing knowledge

transfer practices over enterprise interfaces more efficiently and effectively. These

key results lead the researcher to make the following recommendations in order to

effectively implement knowledge transfer in requirements engineering in the

context of collaborative product development:

Globalisation trends

Structural changes in supply chain

Structural changes in high-tech industry

The complexity of product development

Collaboration in product development

Knowledge transfer over enterprise interfaces

Need to:

-Build relationships

-Ensure effective transfer

Quality of requirements (fit with stakeholders’

needs)

Increasing importance of

knowledge transfer in CPD

Challenges

Challenges Challenges

Change in implementation of product development

Product development performance

Product/Service Quality

Page 90: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

88

1. Companies should define common and standardised collaborative product

development, requirements engineering and knowledge transfer processes

between buyers and suppliers. They should also identify the scope of

responsibility of all people involved. Standardising common practices helps

people have a clear vision and mission of what they have to do and how to do

it.

2. Companies should set up standards for how people decide what kinds of

information and knowledge to share, and with whom to share it.

3. Companies should have a common platform or tool to support the

development process over enterprise interfaces.

4. Companies should create a system that automates and integrates information

and knowledge both inside the company and across company boundaries.

5. Companies should establish a network actor role who will take responsibility

as a key contact person to communicate with the suppliers. This role should

not be promoted by position, but rather because he or she really plays a

crucial role in the collaboration network.

6. Companies should build a long-term relationship with the suppliers. Good

relations and a trusting partnership lead to successive adaptations between the

firms to the other’s working process, as well as helping the cooperation to run

more easily and smoothly.

7. Collaboration with external firms creates a lot more difficulties in organising

meetings and it also creates more costs (especially travel expenses) than

working within the company, but it is crucial for developing a product.

Therefore, companies should be aware of supporting communication with the

supplier, especially person-to-person communication.

Page 91: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

89

4 Discussion

4.1 Theoretical implications

This research contributes theoretically to the field of product development,

knowledge transfer and requirements engineering by creating a study of

knowledge transfer in requirements engineering in the collaborative product

development context. It contributes by discussing the challenges of collaborative

product development that were found from the case studies and focusing on

creating a framework to analyse knowledge transfer and interaction patterns in

collaborative product development. This study also provides new knowledge

about the engagement between the early phase of product development (the

requirements engineering process) and knowledge transfer. Additionally, it

contributes by identifying the challenges related to knowledge transfer in the

requirements engineering process and the means to overcome these challenges.

A summary of the theoretical implications is presented in Table 13.

Table 13. Theoretical implications.

Article Article title Theoretical implications

I Developing new product through collaboration

in high-tech enterprises

- Prioritise the challenges of CPD from the

literature

II Knowledge transfer pattern in collaborative

product development

- Developing typication of transferred knowledge

- Developing an analysis framework for the

knowledge transfer pattern

- Description of knowledge transfer pattern

III Interaction patterns in collaborative product

development

- Developing an analysis framework for

interaction patterns between individuals or

organisations

- Description of interaction pattern

IV The engagement between knowledge transfer

and requirements engineering

- Verify and prioritise the challenges of

knowledge transfer in RE from the literature and

found a new one

V Organising knowledge transfer in requirements

engineering over organisational interfaces

- Developing the means to overcome the

challenges of knowledge transfer in RE

Challenges of CPD: This article discusses the challenges of CPD that high-tech

companies are facing and describes how these challenges affect CPD in the high-

tech companies. The list of the challenges found in this research complements the

previous studies (e.g. Audretsch 2008; Cooper 2001; Emden et al. 2006; Jiaxi

Page 92: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

90

2009; Lam & Chin 2005; Littler et al. 1995; Squicciarini & Loikkanen 2008;

Ulrich & Eppinger 2008). The impact of the challenges is somewhat similar to the

earlier studies, but still, there are several differences such as negotiation strategies

and mutual trust. Furthermore, prioritisation of these challenges is conducted in

this research.

Knowledge transfer pattern in CPD: This paper clarifies how knowledge is

transferred between buyers and suppliers in collaborative product development.

The concept of knowledge to be transferred is introduced, combined with the

transfer methods (Dixon 2000; Inkpen & Dinur 1998; Martins & Antonio 2010)

to create a basis for a knowledge transfer pattern analysis framework. This paper

provides a new scientific perspective by developing an additional new dimension

– transfer frequency, in order to analyse the knowledge transfer in different

product development phases. This is a new framework that combines the existing

theoretical concepts of knowledge transfer. For this framework, the pattern of

knowledge transfer can be analysed according to three dimensions: types of

transferred knowledge, transfer methods and transfer frequency. This paper also

provides a new type of knowledge to be transferred by combining the existing

types of knowledge proposed by previous authors (e.g. Brusoni et al. 2001;

Cohen & Bacdayan 1994; Inkpen & Pien 2006; Lunghua et al. 2010; Nonaka

1994; Polanyi 1962; Small & Sage 2006) and developing a new kind of

classification of transferred knowledge for this research including explicit

engineering knowledge, tacit engineering knowledge, explicit managerial

knowledge and tacit managerial knowledge.

Interaction pattern in CPD: This paper describes the pattern of individual

interactions while transferring knowledge in collaborative product development

and clarifies the benefits of relationships between buyers and suppliers in

collaborative product development. The concept of social network is introduced

as a basic knowledge for studying the interaction between people. The

characteristics of social network and relationships are summarised and discussed

in order to create a basis for the interaction pattern analysis framework. This

study creates new knowledge by developing the framework to analyse interaction

patterns while transferring knowledge through social network analysis. This

framework has been created based on the studies of previous authors (Anklam

2005; Scott 1999; Streeter & Gillespie 1992; Wasserman & Faust 1997). This

analysis framework is new and combines the two perspectives (the relational

properties and the structural properties) to analyse interaction patterns while

transferring knowledge through social network analysis.

Page 93: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

91

Challenges of knowledge transfer in the requirements engineering process:

This paper contributes theoretically to the field of knowledge transfer and the

requirements engineering process by providing new knowledge on how

knowledge transfer engages with the requirements engineering process.

Furthermore, the challenges of knowledge transfer in the requirements

engineering process are summarised from various previous studies (e.g. Bubenko

1995; Damian 2007; Kotonya & Sommerville 1998; McAllister 2006; Naz &

Khokhar 2009; Pilat & Kaindl 2011; Sommerville 2006; Wiegers 2003; Zagajsek

et al. 2007) in order to form an initial list of transfer challenges in the

requirements engineering process. These challenges are classified into three main

groups: human-, process- and context-oriented factors. This study complements

the earlier studies by updating and expanding the understanding of knowledge

transfer challenges in the requirements engineering process. In contrast to

previous studies, some of the challenges found in previous studies did not seem to

be a problem in this study. Additionally, this paper provides new theoretical

knowledge by finding four new challenges that create some difficulties in

transferring knowledge in the requirements engineering process – experience of

the organisation, experience of the management, implementation of processes and

the company’s internal process.

Organising knowledge transfer in the requirements engineering process: This

paper discusses how to overcome the challenges of requirements transfer over

enterprise interfaces. It contributes by providing a discussion about the means or

solutions to solve any difficulty in transferring knowledge in the requirements

engineering process that were found in earlier studies. This research complements

previous studies (e.g. Al-Salti & Hackney 2011; Bhat et al. 2006; Damian &

Zowghi 2003; Mallick & Krishna 1999) by providing more tangible means to

overcome the challenges of knowledge transfer in the requirements engineering

process. Additionally, this paper creates new knowledge by creating four main

areas to handle the challenges.

Overall, this research provides new information by studying collaborative

product development through the knowledge transfer perspective from various

previous studies. Consequently, this dissertation provides a better understanding

of how to make CPD more efficient and effective by describing the current

challenges related to CPD and knowledge transfer, explaining the impact of these

challenges, providing a tangible framework to analyse knowledge transfer and

interactions between buyers and suppliers in CPD, and providing tangible means

to overcome any difficulties during CPD.

Page 94: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

92

4.2 Practical implications

This dissertation contributes to enhancing understanding of knowledge transfer

over enterprise interfaces. The idea is to recognise how companies collaborate

with their suppliers in the product development process. This study not only

contributes to a better understanding of knowledge transfer between buyers and

suppliers and the important of knowledge transfer in the requirements engineering

process but also enhances our understanding of the role of social network in joint

product development and how to make collaborative product development

between buyers and suppliers more effective and efficient. The phenomenon in

itself is crucial while product lifecycles are shortening and competition is getting

fierce. The importance of this research in high-tech companies is even higher than

in other companies, because high-tech companies are becoming product

development labs instead of having a great deal of manufacturing capacity. The

summary of managerial implications is presented in Table 14.

Table 14. Managerial implications.

Article Article title Theoretical implications

I Developing new product through

collaboration in high-tech enterprises

- Understanding of the importance of collaborative

product development

Learning from the challenges identified and prioritised by

other companies

II Knowledge transfer pattern in

collaborative product development

- Ideas on how to manage the knowledge transfer

between buyer and supplier in different phases of product

development in order to facilitate effective knowledge

transfer

- Understanding of the importance of knowledge transfer

in collaborative product development

III Interaction patterns in collaborative

product development

- Ideas on how to manage the interaction between buyer

and supplier in order to facilitate effective knowledge

transfer

- Understanding of the importance of buyer and supplier

relationships in transferring knowledge

- To organise individual, subgroup and total network

setup in new collaboration projects

IV The engagement between knowledge

transfer and requirements

engineering

- Understanding of the importance of knowledge transfer

in the requirements engineering process

- Learning from the challenges identified and prioritised

by other companies

Page 95: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

93

Article Article title Theoretical implications

V Organising knowledge transfer in

requirements engineering over

organisational interfaces

- Learning from the solutions identified by other

companies

- Identification of potential means to overcome the

challenges

Challenges of CPD: This study explains how the challenges of CPD affect the

case companies. It not only contributes to a better understanding of the CPD

process, but also provides insights into what the most important aspects of CPD

in special know-how are in the high-tech field of business. It also helps the

company prepare to solve any difficulties it may face, as well as develop the work

processes required to meet all possible challenges.

Knowledge transfer pattern in CPD: This paper examines ways of

transferring knowledge between buyers and suppliers during product development

work. The paper creates an analysis framework to analyse knowledge transfer and

discusses the pattern of knowledge transfer between buyers and suppliers in

different phases of product development.

Regarding the findings, knowledge is important, especially tacit knowledge.

However, such knowledge would never be useful if it resides in only one person.

In order to make the knowledge fruitful, it needs to be transferred. Transferring

knowledge not only entails what kind of knowledge is transferred, but it also

includes the transfer methods and the transfer frequency. Knowledge is

transferred most effectively when the transfer process fits the knowledge being

transferred and the capacity of the transfer methods, which are likely to be

different at each phase of product development. Some methods have a very

important role in some phases, but not in others. Additionally, although the

electronic method plays an important role in CPD, an electronic system cannot

replace personal interactions and documents.

Therefore, the development of an appropriate knowledge transfer pattern has

a very important role in the effectiveness of knowledge transfer. These findings

benefit companies as the results gained could be applied for the most effective

knowledge transfer between companies in order to continuously produce

innovative products.

Interaction pattern in CPD: This paper provides in-depth studies of how

buyers and suppliers interact whilst transferring knowledge in collaborative

product development. It helps to better understand the individual interactions

between the high-tech companies (who are the buyers) and their suppliers and

Page 96: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

94

emphasises the importance of buyer-supplier relationships. This research provides

companies with a view of the informal and often hidden dynamics in CPD –

where influence lies, unofficial knowledge channels, who the key players are, and

how knowledge, ideas and innovation form.

Challenges of knowledge transfer in the requirements engineering process:

This article discusses the difficulty in transferring knowledge in the requirements

engineering process. Current challenges of knowledge transfer in the

requirements engineering process are presented. Knowing and understanding

these challenges should help ensure that companies are able to deal with the

increasing challenges in order to keep up with the pace of knowledge transfer in

collaborative product development and prepare to solve many of the problems the

companies are facing.

Organising knowledge transfer in the requirements engineering process: This

paper discusses ways to facilitate effective requirements knowledge transfer. The

means to overcome the challenges of requirements knowledge transfer are

developed. Each practical solution for the challenges is probably case-dependent.

However, the area of means for overcoming the challenges may be more

generalizable and serve as guidance for managing and ensuring better

requirements transfer among organisational interfaces. Companies can use these

means as managerial actions to overcome requirements knowledge transfer

challenges.

Overall, this research provides better understanding of knowledge transfer in

requirements engineering in the collaborative product development context and

provides insight into potential ways of improving the knowledge transfer and

collaborative product development strategy so that knowledge transfer over

enterprise interfaces can be facilitated and improved. It also provides a

competitive advantage for the companies, since the increasing number of new

emerging technologies with shorter lifecycles in different fields will heighten the

importance of product development. The results of this research have direct

applications and utility in the companies.

4.3 Reliability and validity

In qualitative research, the focus is primarily on understanding a particular

phenomenon rather than generalising to universals. There is a large variety of

methods used in qualitative research. In this dissertation, the case study was

selected since it allows the researcher to study a phenomenon in its real situation

Page 97: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

95

and it provides a broad view of the phenomenon. Reliability and validity are two

issues that quality research should be concerned about while designing a study

(Creswell 2009; Patton 2002; Yin 2009). These issues are meant to differentiate

good research from bad research.

Reliability

Reliability concerns the consistency of the researcher’s approach across the

difference of researchers and projects (Creswell 2009). The reliability of the

research can be enhanced by standardising data collection methods and protocols,

recording and documenting collected data, using multiple researchers, using a

structured or semi-structured case study protocol (LeCompte & Goetz 1982;

Riege 2003; Yin 2009).

In this research, the researcher enhances the reliability in various ways. The

detailed case study procedures have been documented and two kinds of

standardised data collection methods – interview and survey – have been used.

The interview method was selected since it is particularly useful to explain the

real context to be studied. (Berg 2007; Yin 2009). The survey method was

selected since the unit analysis is distributed geographically (across Finland,

England and Thailand). The same data collection procedure was followed for

each case and a consistent set of interview questions was used in each interview.

Reliability can also be improved by recording, transcribing and storing the

collected data in a systematic way as well as using two interviewers to conduct

the interviews. In the data analysis phase, the collected data was coded in order to

easy for accessing data, making comparison, analysing patterns that required

further study. In this research, NVivo coding software tools are used to assist in

coding and in helping to organise the resulting patterns. Additionally, reliability

can be enhanced by allowing the informants to review and comment on the

empirical material and the working drafts of the empirical analysis. In addition to

using the interviewees as a means for higher reliability, another researcher was

also involved in reading through and commenting on the descriptions in this

research project. However, it would be hard to repeat the same research and

obtain the same results due to changes in the context and situation and because

qualitative research is not objective – it is often subjective (Yin 2009). Thus,

conducting the same research process in other companies would probably provide

at least slightly different results.

Page 98: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

96

Validity

Validity concerns the degree to which a finding is judged to have been interpreted

in a correct way – meaning that the researcher checks for the accuracy of the

findings by using suitable procedures (Creswell 2009). In case study research,

there are three kinds of validity: construct validity, external validity and internal

validity (Yin 2009).

Construct validity concerns the establishment of a correct and suitable

research setting for the concepts being studied. According to Yin (2009), there are

three ways to increase construct validity: using multiple sources of evidence in

the data collection, establishing a chain of evidence and letting key informants

and research assistants review a draft of the case study report.

In this research, the above ways were implemented. Using multiple sources

of evidence has been done through using data triangulation (Eriksson &

Kovalainen 2008). Data triangulation involves the use of a wide range of

informants. With data triangulation, the same issue is studied from various

perspectives that complement and verify each other. The data in this study was

collected from the different roles and positions of the informants. The empirical

material has been recorded and transcribed and then the case study report has

been sent to the key informants to review and comment on.

External validity concerns the ability of the results to be applied to other

contexts (generalisation). Generalisation is used in a limited way in quality

research, since the intent is not to generalise findings, but rather to explore a

particular phenomenon in the context where they occur. External validity can be

attained through giving a definition of the scope and boundaries, and making a

comparison of evidence with the extant literature (Eisenhardt 1989; Yin 2009).

In this research, the importance of the researcher outlining the boundaries of

the study have been highlighted and clearly presented. They include the number

of case companies taking part in the study and where they operate, the roles and

positions of the informants, the number of informants involved in this research,

and the data collection methods that were employed. The same criterion for

selecting the case companies and informants has been implemented for every case

study. This research was conducted in high-tech companies, including a few large

companies and some medium-sized companies. These companies have long

traditions of continuous collaborative product development and have been

developing a product development process for years. The interviewees were

carefully selected on the basis of their professional background and expertise. The

Page 99: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

97

experience and the current interests ensured high motivation among the

participants and up-to-date knowledge of the topics discussed. The total work

experience of those interviewed was typically between ten and 20 years.

Regarding generalisation, this research draws analytical generalisations of high-

tech collaborative product development projects. The results can be applicable to

the specific company studied at that precise moment in time. The results might be

too limited to apply outside that specific context. Additionally, external validity

can be achieved by comparing the research results with the literature, in order to

clearly outline contributions and generalise those within the scope and boundaries

of this research. A literature review was conducted at the beginning of the

research. It gradually builds up knowledge about the studied topic.

Internal validity views the research results as less important than the process

of finding out. The participants in the research are the person who judges the

research’s credibility. It is the validity of causal inferences in scientific studies.

Internal validity is reached when the results are seen as believable by the

participants in the research.

In this dissertation, the internal validity has been enhanced in many ways.

1) Tactics to encourage informants to be honest when contributing data were used.

The researcher introduced the informants to the objective of the study, explained

the interview questions and established an environment of rapport during the

interviews by letting them know that there are no right answers to the questions.

They were also informed that their names would be handled anonymously in the

research. Consequently, informants could contribute ideas and discuss the studied

topic without fear of losing credibility in the eyes of the executive level of the

company. 2) The accuracy of the collected data was checked. After each interview,

the researcher asked the informants to read their transcripts in order to check that

their transcripts accurately matched what they actually intended. 3) The research

approaches were discussed with the supervisor and other researchers. This

discussion helped the researcher to get a broader view of the research approaches

and related issues. 4) Other researchers were integrated into the data analysis

phase of the research. This researcher’s role is to provide a fresh perspective for

analysis and critique. 5) A double-blind review process was used. Each article has

been reviewed and commented on by members of the scientific community. The

feedback offered from the scientific community enables the researcher to develop

and strengthen the research work.

Page 100: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

98

Table 15. Actions taken to enhance the research quality.

Strategies to

establish research

quality

Actions taken in this dissertation Research phase in

which action was

undertaken

Reliability Develop and refine case study in detail and follow the same

data collection procedure for each case

Research design and

data collection

Conduct standardised data collection methods – interview

and survey

Data collection

Record, transcribe and store data systematically Data collection

Code data systematically – using NVivo program Data analysis

Informants and other researchers review the empirical

material and working drafts

Data analysis

Construct validity Use data triangulation Data collection

Informants and other researchers review and comment on

the working drafts

Data analysis

External validity Identify the scope and research boundary clearly (place and

number of case companies, number of informants, data

collection methods)

Research design

Compare the results with the literature Data analysis

Internal validity Create an environment of rapport to encourage honesty in

informants

Data collection

Check the accuracy of the collected data with the informants Data analysis

Discuss the research approaches with the supervisor and

other researchers

Research design

Integrate other research in the data analysis phase Data analysis

Use a double-blind review process Dissemination

4.4 Recommendations for further research

This study aims to enhance the understanding of knowledge transfer in

requirements engineering in the context of collaborative product development.

This study presents the challenges related to collaboration in the product

development process and the requirements engineering process, together with the

pattern of knowledge transfer and individual interaction. Additionally, practical

descriptions of means to manage the knowledge transfer practices are developed.

There are several possibilities for research extension. Since the information

and knowledge flow in the product development process is crucial and involves a

number of different people, further research could include studying the

relationship between the pattern of knowledge transfer and other constructs, such

as different organisational cultures and inter-culture issues. More studies about

Page 101: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

99

how to transfer requirements, especially tacit requirements, over organisational

boundaries are also required in order to make requirements transfer more efficient.

Additionally, further research could include measuring the outcome of

knowledge transfer in collaborative product development. It would also be

valuable to study how to improve collaborative product development, for example

conducting a long-term study (longitudinal research) of companies that applied

the means to overcome the challenges of knowledge transfer. Also more research

on the requirements engineering area is needed. As a result of this dissertation, it

is clearly evident that many requirements should be presented differently whether

they are going to be fulfilled inside or outside the company. Therefore, potential

further research could include specification differences and whether they fulfil

internal or external firms.

This study was conducted in a few high-tech companies and is studied from

the buyer company’s perspective. Further studies involving a larger number of

companies and a broader spectrum of companies (rather than just high-tech

companies) are needed. Moreover, studies on collaborative product development

from the supplier perspective should be carried out. This could include, for

example research concerning the supplier and its reason for entering collaboration

with the buying firm by studying the criteria that the suppliers use for joining a

product development project. Potential further study could also include a

comparison between the supplier’s criteria and the buyer’s criteria for

collaborative product development in order to identify the differences and

similarities.

Page 102: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

100

Page 103: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

101

References

Aadne JH, von Krogh G & Roos J (1996) Representationism: the traditional approach to cooperative strategies. In von Krogh G & Roos J (eds.): Managing knowledge. Perspectives on cooperation and competition. London, Sage: 9–31.

Abbott RJ (1986) An Integrated Approach to Software Development. New York, John Wiley.

Abrahamsson P, Warsta J, Siponen MT & Ronkainen J (2003) New directions on agile methods: A comparative analysis. In: Proceeding of the International Conference on Software Engineering, Portland, Oregon, USA.

Ackoff RL (1989) From Data to Wisdom. Journal of Applies Systems Analysis 16: 3–9. Al-Salti Z & Hackney R (2011) Factors impacting knowledge transfer success in

information systems outsourcing. Journal of Enterprise Information Management 24(5): 455 – 468.

Albino V, Garavelli AC & Schiuma G (1999) Knowledge transfer and inter-firm relationships in industrial districts: the role of the leader firm. Technovation 19(1): 53–63.

Alford MW (1977) A Requirements Engineering Methodology for Real-Time Process Requirements, IEEE Transactions on Software Engineering, 3(1): 60–69.

Allard K (1996) Command, Control, and the Common Defense. rev. ed. Washington, National Defense University. Almeida P & Grand R (1998) International Co-operation and Cross-Border Knowledge

Transfer in the Semiconductor Industry. Working Paper. Carnegie Bosch School. Alves C, Ramalho G & Damasceno A (2007) Challenges in Requirements Engineering for

Mobile Games Development: The Meantime Case Study. In: Proceeding of IEEE International Conference on Requirements Engineering, Los Alamitos, California.

Anderson JC, Håkansson H & Johanson J (1994) Dyadic business relationships within a business network context. Journal of Marketing 58(4): 1–15.

Anderson JC & Narus JA (1990) A Model of Distributor Firm and Manufacturer Firm Working Partnerships. Journal of Marketing 54(1): 42–58.

Anderson M & Holmes J (1995) New models of industrial organization: the case of Magna International. Regional Studies 29(7): 655–671.

Anklam P (2005) The Social-Network Toolkit. The Ask Group. Ansari A & Modarress B (1994) Quality Function Deployment: The Role of Suppliers.

Journal of Supply Chain Management 30(4): 27–35. Appleyard MM (1996) How Does Knowledge Flow? Inter-Firm Patterns in the

Semiconductor Industry. Strategic Management Journal 17(Winter Special Issue): 137–154.

Argote L (1999) Organizational Learning: Creating, Retaining and Transferring Knowledge. Norwell, MA: Kluwer Academic Publishers.

Argote L & Ingram P (2000) Knowledge Transfer: A Basis for Competitive Advantage in Firms. Organization Behavior and Human Decision Processes 82(1): 150–169.

Page 104: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

102

Arnzten-Bechina AA & Leguy CAD (2007) A model of Knowledge sharing in Biomedical engineering: Challenges and Requirements. Journal of Chemistry 4(1): 21–32.

Asghar S & Umar M (2010) Requirement Engineering Challenges in Development of Software Applications and Selection of Customer-off-the-Shelf (COTS) Components. International Journal of Software Engineering 1(1): 32–50.

Atuahene-Gima K (1996) Differential potency of factors affecting innovation performance in manufacturing and services firms in Australia. Journal of Product Innovation Management 13(1): 35–52.

Audretsch D (2008) Globalisation, knowledge, entrepreneurship and new growth strategies. In Squicciarini M & Loikkanen T (eds.): Going Global – The Challenges for Knowledgebased Economies. Ministry of Employment and the Economy, Helsinki, Finland. Edita Publishing: 30–43.

Awad E & Ghaziri H (2003) Knowledge Management. New Jersey, Pearson Education. Aylen J (2010) Open versus closed innovation: development of the wide strip mill for steel

in the United States during the 1920s. R&D Management 40(1): 67–80. Bahill AT & Dean FF (1999) Discovering system requirements. In Sage AP & Rouse WB

(eds.): Handbook of System Engineering. John Wiley & Sons: 175–220. Baldwin C & Clark K (2003) Where do Transactions Come From? A Perspective from

Engineer Design. Working Paper No. 03-031, Harvard Business School. Beichter FW, Herzog O & Petzsh H (1984) SLAN-4-A Software Specification and Design

Language. IEEE Transactions on Software Engineering SE-10 (2): 155–162. Benington H (1983) Production of large computer programs. IEEE Annals of the History

of Computing 5(4): 350–361. Bensaou M (1999) Portfolios of buyer-supplier relationships. Sloan management review

40(4):35–44. Berg B (2007) Qualitative Research Methods for the Social Sciences. 6th ed. Boston,

Pearson Education. Bhat J, Gupta M & Murthy S (2006) Overcoming Requirements Engineering Challenges:

Lessons from Offshore Outsourcing. IEEE Software 23(5): 38–44. Bhatt GD (2001) Knowledge management in organisations: examining the interaction

between technologies, techniques, and people. Journal of Knowledge Management. 5(1): 68–75.

Bierly P, Kessler E & Christensen E (2000) Organizational learning, knowledge and wisdom. Journal of Organizational Change Management 13(6): 595–618.

Birou L & Fawcett S (1994) Supplier involvement in integrated product development: a comparison of US and European practices. International Journal of Physical Distribution and Logistics Management 24(5): 4–14.

Birrell ND & Ould MA (1985) A practical handbook for software development. Cambridge, Cambridge University Press.

Blonder C & Pritzl R (1992) Developing strategic alliances: a conceptual framework for successful co-operation. European Management Journal 10(4): 412–421.

Page 105: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

103

Bloodgood J & Salisbury W (2001) Understanding the influence of organizational change strategies on information technology and knowledge management strategies. Decision Support Systems 31(1): 55–69.

Blumenberg S, Wagner HT & Beimborn D (2009) Knowledge transfer processes in IT outsourcing relationships and their impact on shared knowledge and outsourcing performance. International Journal of Information Management 29(5): 342–352.

Boehm B (2002) Get Ready For The Agile Methods, With Care. Journal Computer 35(1): 64–69.

Borgatti SP & Molina J-L (2003) Ethical and strategic issues in organizational network analysis. Journal of Applied Behavioral Science 39(3): 337–350.

Bou-Llusar JC & Segarra-Cipres M (2006) Strategic knowledge transfer and its implications for competitive advantage: an integrative conceptual framework. Journal of Knowledge Management 10(4): 100–112.

Bozdogan K, Deyst J, Hoult D & Lucas M (1998) Architectual innovation in product development through early supplier integration. R&D management 28(3): 163–173.

Brackett JW (1990) Software Requirements. SEI Curriculum Module SEI-CM-19-1.2. Carnegie Mellon University, Software Engineering Institute.

Brooks FP (1987) No Silver Bullet — Essence and Accidents of Software Engineering. IEEE Computer 20(4): 10–19.

Brown JS & Duguid P (2000) The social life of information. Boston, Harvard Business Books Press.

Bruce M, Leverick F, Littler D & Wilson D (1995) Success factors for collaborative product development: a study of suppliers of information and communication technology. R&D Management 25(1): 33–44.

Brusoni S, Prencipe A & Pavitt K (2001) Knowledge, specialization, organizational coupling, and the boundaries of the firm: Why do firms know more than they make?’. Administrative Science Quarterly 46(4): 597–621.

Bryman A & Bell E (2007) Business Research Methods, Second Edition. Oxford. Oxford University Press.

Bubenko JA (1995) Challenges in Requirements Engineering. In: Proceeding of the Second IEEE International Symposium on Requirements Engineering. York, England: 160–164.

Buede DM (1997) Developing originating requirements: defining the design problem. IEEE Transactions on Aerospace and Electronic System 33(2): 596–609.

Cavusgil S, Calantone R & Zhao Y (2003) Tacit knowledge transfer and firm innovation capability. Journal of Business & Industrial Marketing 18(1): 6–21.

Cetinkaya B (2011) Developing a Sustainable Supply Chain Strategy. In Cetinkaya B, Cuthbertson R, Ewer G, Klaas-Wissing T, Piotrowicz W & Tyssen C (eds.): Sustainable Supply Chain Management: Practical Ideas for Moving Towards Best Practice. Springer Berlin Heidelberg: 17–55.

Page 106: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

104

Chakrabarti A (2003) Role of University in the product development process: Strategic considerations for the telecommunications industry. In: Korhonen T & Ainamo A (eds.): Guide to High Tech Product Development for Telecommunication. Munich, Germany, Kluwer Academic Publishers.

Chang JR & Chu CH (2004) Collaborative Product Development in PCB Industry. International Journal of Electronic Business Management 2(2): 108–116.

Chen S, Duan Y, Edwards JS & Lehaney B (2006) Toward understanding inter organizational knowledge transfer needs in SMEs: insight from a UK investigation. Journal of Knowledge Management 10(3): 6–23.

Chesbrough Henry (2007) Why Companies Should Have Open Business Models. Sloan Management Review 48(2): 22–28.

Chesbrough H (2003) Open Innovation: The New Imperative for Creating and Profiting from Technology. Boston, Harvard Business Review Press.

Chong CW, Chong SC & Gan GC (2011) Inter-organizational knowledge transfer needs among small and medium enterprises. Library Review 60(1): 37–52.

Cockburn A (2002) Agile software development. Boston, Addison-Wesley. Cohen MD (1991) Individual learning and organizational routine: emerging connections.

Organization Science 2(1): 135–139. Cohen MD & Bacdayan P (1994) Organizational routines are stored as procedural memory:

evidence from a laboratory study. Organization Science 5(4): 554–568. Cohen WM & Levinthal DA (1990) Absorptive capacity: A new perspective on learning

and innovation. Administrative Science Quarterly 35(1): 128–152. Cohen WM & Levinthal DA (1989) Innovation and learning: the two faces of R&D. The

Economic Journal 99(397): 569–596. Cooper RG (2011) Winning at New Products: Creating Value Through Innovation. 4th ed.

New York, Basic Books. Coughlan J & Macredie R (2002) Effective Communication in Requirements Elicitation: A

Comparison of Methodologies. Requirements Engineering 7(2): 47–60. Cowell DW (1988) New service development. Journal of Marketing Management 3(3):

313–27. Creswell JW (2009) Research Design: Qualitative, Quantitative, and Mixed Methods

Approaches. 3rd ed. London, Sage. Croom SR (2001) The dyadic capabilities concept: examining the processes of key

supplier involvement in collaborative product development. European Journal of Purchasing & Supply Management 7: 29–37.

Cross R & Parker A (2004) The Hidden Power of Social Networks: Understanding How Work Really Gets Done in Organizations. Boston, Massachusetts, Harvard Business School Press.

Damian D (2007) Stakeholders in Global Requirements Engineering: Lessons Learned from Practice. IEEE Software 24(2): 21–27.

Damian D & Zowghi D (2003) RE challenges in multi-site software development organizations. Requirements Engineering 8(3): 149–160.

Page 107: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

105

Daniel HZ, Hempel DJ & Srinavasan N (2002) A Model of Value Assessment in Collaborative R&D Programs. Industrial Marketing Management 31(8): 653–664.

Davenport TH (1997) Information Ecology, Mastering Information and Knowledge Environment. Oxford, UK, Oxford University Press.

Davenport TH & Prasak L (2000) Working Knowledge – How Organizations Manage What They Know. Boston, Massachusetts, Harvard Business School Press.

Davis AM (1993) Software Requirements: Objects, Functions, and States. New Jersey, Prentice Hall, Englewood Cliffs.

Davis AM (1992) Operational prototyping: A new development approach. IEEE Software, 9(5): 70–78.

Defense Acquisition University (2001) Systems Engineering Fundamentals, Defense Acquisition University Press.

Den-Hertog P (2000) Knowledge-intensive business services as co-producers of innovation. International Journal of Innovation Management 4(4): 491–528.

Desouza KC & Awazu Y (2004) Need-to-know: organizational knowledge and management perspective. Information Knowledge Systems Management 4(1): 1–14.

Ding Q (2011) Interfirm Alliance Linkages and Knowledge Transfer: An Exploratory Analysis of Mutual Cooperative Learning in an International Joint Venture in the Chinese Automotive Industry. Doctoral Dissertation. University of Waikato, New Zealand

Distanont A, Haapasalo H, Rassameethes B & Lin B (2012) Knowledge transfer pattern in collaborative product development. International Journal of Intercultural Information management 3(1): 59–81.

Distanont A, Haapasalo H, Kamolvej T & Meeampol S (in press) Interaction patterns in collaborative product development (CPD). International Journal of Synergy and Research.

Distanont A, Haapasalo H, Vaananen M (in press) Organising knowledge transfer in requirements engineering over organisational interfaces. International Journal of Innovation and Learning.

Dixon NM (2000) Common Knowledge: How Companies Thrive by Sharing What they Know. Boston, Harvard Business School Press.

Dowlatshahi S (1998) Implementing early supplier involvement: a conceptual framework. International Journal of operations and production management 18(2): 143–167.

Dwyer FR, Schurr PH & Oh S (1987) Developing buyer-seller relationships. Journal of Marketing 51(2): 11–27.

Easterby-Smith M, Lyles MA & Tsang EWT (2008) Inter-Organizational Knowledge Transfer: Current Themes and Future Prospects. Journal of Management Studies, 45(4): 677–690.

Edvardsson B, Gustafsson A , Johnson M & Sandén B (2000) New service development and innovation in the new economy. Lund, Studentliteratur.

Eisenhardt KM (1989) Building theories from case study research. Academy of Management Review 14(4): 532–550.

Page 108: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

106

Ellram L (1990) The Supplier Selection Decision in Strategic Partnerships. Journal of Purchasing and Materials Management 26(4): 8–14.

Emden Z, Calantone R & Droge C (2006) Collaborating for new product development: selecting the partner with maximum potential to create value. Journal of Product Innovation Management 23(4): 330–341.

Eriksson P & Kovalainen A (2008) Qualitative Methods in Business Research. 1st ed. London, Sage Publications.

Farr CM & Fischer WA (1992) Managing international high technology cooperative projects. R&D Management 22(1): 55–67.

Ferry J (2004) Flextronics: Staying Real in a Virtual World. strategy+ business Magazine 30(37): 1–9.

Fliess S & Becker U (2006) Supplier integration—Controlling of co-development processes. Industrial Marketing Management 35(1): 28–44.

Firesmith D (2003) Using Quality Models to Engineer Quality Requirements. Journal of Object Technology 2(5): 67–75.

Fox JM (1982) Software and its development. Englewood Cliffs, NJ, Prentice-Hall. Galliers RD (1991) Choosing Appropriate Information Systems Research Approaches. In

Nissen H, Klein H & Hirschheim R (eds): Information Systems Research: Contemporary Approaches and Emergent Traditions. North-Holland, Elsevier Science Publishers, 327–345.

Gallouj F & Weinstein O (1997) Innovation in services. Research Policy 26(4/5): 537–556. George G, Zahra S, Wheatley K & Khan R. (2001) The effects of alliance portfolio

characteristics and absorptive capacity on performance: a study of biotechnology firms. Journal of High Technology Management Research 12(2): 205–226.

Gershenson JA & Stauffer LA (1995) The creation of a taxonomy for manufacturability design requirements. In: Proceeding of the 7th International Conference of Design Theory and Methodology. Boston, Massachusetts.

Giannakis M (2008) Facilitating learning and knowledge transfer through supplier development. Supply Chain Management 13(1): 62–72.

Gilbert M & Cordey-Hayes M (1996) Understanding the process of knowledge transfer to achieve successful technological innovation. Technovation 16(6): 301–312.

Glass RL (1998) Software runaways. USA, Prentice-Hall. Goffin K, Koners U, Baxter D & van der Hoven C (2010) Managing lessons learned and

tacit knowledge in new product development. Research Technology Management 53(4): 39–51.

Grady JO (1993) System requirements analysis. New York, McGraw Hill. Grant RM & Baden-Fuller C (2004) A knowledge accessing theory of strategic alliances.

Journal of Management Studies 41(1): 61–84. Griffin A (1997) Modeling and measuring product development cycle time across

industries. Journal of Engineering and Technology Management 14(1): 1–24. Guion, RM (2002) Validity and reliability. In: Rogelberg SG (ed.): Handbook of research

methods in industrial and organizational psychology. Malden, MA, Blackwell Publishers: 57–76.

Page 109: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

107

Gulati R, Nohria N, Zaheer A (2000) Strategic networks. Strategic Management Journal 21(3): 203–216.

Gules H & Burgess T (1996) Manufacturing technology and the supply chain: linking buyer–supplier relationships and advanced manufacturing technology. European Journal of Purchasing and Supply Management 2(1): 31–38.

Gupta AK & Govindarajan V (2000) Knowledge flows within multinational corporations. Strategic Management Journal 21(4): 473–496.

Hall R & Andriani P (2002) Managing knowledge for innovation. Long Range Planning 35(1): 29–48.

Hamel G, Doz Y & Prahalad C (1989) Collaborate with your competitors and win. Harvard Business Review 67(1): 133–139.

Handfield R, Ragatz G, Petersen K & Monczka R (1999) Involving suppliers in new product development. California Management Review 42(1): 59–82.

Hannabuss S (1996) Research interviews. New Library World 97(5): 22 – 30. Hansen M (1999) The search-transfer problem: the role of weak ties in sharing knowledge

across organization subunits. Administrative Science Quarterly 44 (1): 82–111. Hansen MT, Mors ML & Lovas B (2005) Knowledge sharing in organizations: Multiple

networks, multiple phases. Academy of Management Journal 48(5): 776–793. Håkansson H & Snehota I (1995) Developing relationships in business networks. Boston,

International Thomson Press. Heiman B & Nickerson J (2002) Towards Reconciling Transaction Cost Economics and

the Knowledge-based View of the Firm: The Context of Interfirm Collaborations. International Journal of Economics and Business 9(1): 97–116.

Herbig P & O’Hara B (1995) Broadening horizons: the practice of global relationships in procurement. Management Decision 33(9): 12–16.

Hertenstein JH & Platt MB (1998) Why product development teams need management accountants. Management Accounting 12(3): 50–55.

Hillebrand B & Biemans WG (2004) Links between internal and external cooperation in product development: An exploratory study. Journal of Product Innovation Management 21(2): 110–122.

Hoegl M & Wagner SM (2005) Buyer–supplier collaboration in product development projects. Journal of Management 31(4): 530–548.

Hooks I & Farry K (2001) Customer-Centred Products:Creating Successful Products Through Smart Requirements Management. USA, Amacom.

Horney N, Pasmore B & O’Shea T (2010) Leadership Agility: A Business Imperative for a VUCA World. People & Strategy 33(4): 32–38.

Hsieh KN (2011) The influence of inter-firm relationships and routines on service development: A study of Taiwanese convenience stores. DPhil thesis. University of Sussex.

Huber GP (1991) Organizational learning: the contributing processes and the literatures. Organizational Science 2(1): pp.88–115.

Humphreys P, Shiu W & Chan F (2001) Collaborative buyer–supplier relationships in Hong Kong manufacturing firms. Supply Chain Management 6(3/4): 152–162.

Page 110: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

108

Hussinger K (2005) Did Concentration on Core Competencies Drive Merger and Acquisition Activities in the 1990s? Discussion Paper No. 05-41, Centre for European Economic Research.

Imrie R & Morris J (1992) A review of recent changes in buyer–supplier relationships. Omega: International Journal of Management Science 20(5/6): 641–652.

Inkpen A & Pien W (2006) An examination of collaboration and knowledge transfer: China–Singapore Suzhou Industrial Park. Journal of Management Studies 43(4): 779–811.

Inkpen A & Dinur A (1998) Knowledge management processes and international joint ventures. Organization Science 9(4): 454–468.

Inkpen A & Tsang E (2005) Social capital networks, and knowledge transfer. Academy of Management Review 30(1): 146–165.

Irvine L & Gaffikin M (2006) Getting in, getting on and getting out: reflections on a qualitative research project. Accounting, Auditing & Accountability Journal 19(1): 115–145.

Jiang L (2005) A framework for the Requirements Engineering Process Development. Doctoral dissertation. University of Calgary, Canada.

Jiaxi W (2009) The impact of inter-organizational relationship on new product development performance with the intermediate role of information sharing. In: Proceedings of the 4th International Conference on Cooperation and Promotion of Information Resources in Science and Technology. Beijing, China: 285–289.

Johne A & Storey C (1998) New service development: a review of the literature and annotated bibliography. European Journal of Marketing 32 (3/4): 184–251.

Johnson P & Duberley J (2000) Understanding Management Research. London, Sage. Kauppinen M (2005) Introducing Requirements Engineering into Product Development:

Towards Systematic User Requirements Definition. Doctoral dissertation. Helsinki University of Technology, Finland.

Kauppinen M, Vartiainen M, Kontio J, Kujala S & Sulonen R (2004) Implementing requirements engineering processes throughout organization: success factors and challenges. Information and Software Technology 46(14): 937–953.

Kent DH (1991) Joint ventures vs non-joint ventures: an empirical investigation. Strategic Management Journal 12(5): 383–393.

Kess P, Torkko, M & Phusavat K (2007) Knowledge sharing and transfer practices in outsourcing relationships. In: Proceeding of 8th Management International Conference on Managing Global Transitions: Globalisation, Localisation, Regionalisation. Portoroz, Slovenia: 997–1005.

Khurana A & Rosenthal SR (1997) Integrating the Fuzzy Front End of New Product Development. Sloan Management Review 38(2): 103–120.

Kikoski KC & Kikoski FJ (2004) The Inquiring Organization: Tacit Knowledge, Conversation, and Knowledge Creation: Skill for 21st-century Organizations. Westport, CT, Praeger Publishers.

Kitchenham B & Pfleeger SL (1996) Software Quality: The Elusive Target. IEEE Software 13(1): 12–21.

Page 111: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

109

Kim J & Wilemon D (2002) Strategic issues in managing innovation’s fuzzy front-end. European Journal of Innovation Management 5(1): 27–39.

Kogut B & Zander U (1992) Knowledge of the firm, combinative capabilities, and the replication of technology. Organization Science 3(3): 383–397.

Koen P, Ajamian G, Burkart R, Clamen A, Davidson J, D’Amore R, Elkins C, Herald K, Incorvia M, Johnson A, Karol R, Seibert R, Slavejkov A & Wagner K (2001) Providing clarity and a common language to the “fuzzy front end”. Research-Technology Management 44(2): 46–55.

Koskinen K & Vanharanta H (2002) The role of tacit knowledge in innovation processes of small technology companies. International Journal of Production Economics. 80(1): 57–64.

Kotonya G & Sommerville I (1998) Requirements Engineering: Processes and Techniques. Chichester, England, John Wiley & Sons.

Koufteros XA, Cheng ETC & Lai KH (2007) “Black-box” and “graybox” supplier integration in product development: Antecedents, consequences and the moderating role of firm size. Journal of Operations Management 25(4): 847–870.

Kraatz MS (1998) Learning by Association? Interorganizational Networks and Adaptation to Environmental Change. Academy of Management Journal 41(6): 621 643.

Kropsu-Vehkapera H, Haapasalo H, Lokkinen S & Phusavat K (2011) The influence of product complexity on order handling process. International Journal of Innovation and Learning 10(2): 123–143.

Kumar R (2005) Research Methodology-A Step-by-Step Guide for Beginners. (2nd ed.). Singapore, Pearson Education.

Lam P & Chin K (2005) Identifying and prioritizing critical success factors for conflict management in collaborative new product development. Industrial Marketing Management 34(8): 761–772.

Lamming RC (1993) Beyond partnership - Strategies for innovation and lean supply. London, Prentice-Hall.

Lamming RC (1986) For better or worse: technical change and buyer–supplier relationships. International Journal of Operations and Production Management 6(5): 20–29.

Lang JC (2004) Social context and social capital as enablers of knowledge integration. Journal of Knowledge Management 8(3): 89–105.

Larman C & Basili VR (2003) Iterative and Incremental Development: A Brief History. IEEE Computer, 36(6): 47–56.

Lau AKW, Tang E, & Yam R (2010) Effects of Supplier and Customer Integration on Product Innovation and Performance: Empirical Evidence in Hong Kong Manufacturers. Journal of Product Innovation Management 27(5): 761–777.

Lawrence B (1997) Unresolved Ambiguity. American Programmer 5(5): 17–22. Lawton-Smith H, Dickson K & Smith SL (1991) There are two sides to every story:

innovation and collaboration within networks of large and small firms. Research Policy 20(5): 457–468.

Page 112: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

110

LeCompte M & Goetz J (1982) Problems of reliability and validity in ethnographic research. Review of Educational Research 52(1): 31–60.

Lee JN (2001) The impact of knowledge sharing, organizational capability and partnership quality on IS outsourcing success. Information & Management 38(5): 323–335.

Lee JN, Huynh MQ & Hirschheim R (2008) An integrative model of trust on IT outsourcing: Examining a bilateral perspective. Information Systems Frontiers 10(2): 145–163.

Leffingwell D & Widrig D (2000) Managing Software Requirements: A Unified Approach Dean. Boston, Addison-Wesley Longman Publishing.

Levin DZ & Cross R (2004) The strength of weak ties you can trust: the mediating role of trust in effective knowledge transfer. Management Science 50(11): 1477–1490.

Li L (2004) Knowledge Transfer within Western Multinationals’ Subsidiary Units in China and Finland: The Impact of Headquarter Control Mechanisms, Subsidiary location and Social Capital. Doctoral thesis, Swedish School of Economics and Business Administration, Finland.

Libing S & Rong C (2007) Analysis on influence factors of knowledge transfer within R&D unit under technological innovation perspective. In: Proceeding of International Conference on Service Systems and Service Management. Chengdu, China.

Li-ping W (2006) The Process of University-to-Industry Knowledge Transfer and Influential Factors. In: Proceeding of International Conference on Service Systems and Service Management. Troyes, France: 804–809.

Littler D, Leverick F & Bruce M (1995) Factors affecting the process of collaborative product development: a study of UK manufacturers of information and communications technology products. Journal of Product Innovation Management. 12(1): 16–32.

Lubars M, Potts C & Richter C (1993) A Review of the State of the Practice in Requirements Modeling. In: Proceedings of the IEEE International Symposium on Requirements Engineering. San Diego, USA, pp. 2–14.

Lunghua T, Ho L, Wu J, Kuo T & Lin C (2010) Exploring the barriers to knowledge flow through formal concept analysis. In: Proceeding of International Conference on Technology Innovation and Industrial Management. Pattaya, Thailand.

Lyons TF, Krachenberg AR & Henke JW.Jr (1990) Mixed Motive Marriages: What's Next for Buyer-Supplier Relations? Sloan Management Review 31(Spring): 29–36.

Macaulay L (1996) Requirements Engineering. London, UK, Springer-Verlag Berlin & Heidelberg.

MacBeth D & Ferguson N (1994) Partnership Sourcing: An Integrated Supply Chain Approach. London, U.K, Pitman Publishing Limited.

Mallick S & Krishna S (1999) Requirements Engineering: Problem Domain Knowledge Capture and the Deliberation Process Support. In: Proceedings of 10th International Workshop on Database and Expert Systems Applications. Florence, Italy: 392–397.

Martin RC (2002) Agile Software Development, Principles, Patterns, and Practices. Upper Saddle River, NJ, Prentice Hall.

Page 113: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

111

Martin J & Antonio N (2010) Knowledge transfer to the subsidiaries operating in overseas. Industrial Management & Data Systems 110(4): 516–531.

Matthyssens P & Van den Bulte C (1994) Getting Closer and Nicer: Partnerships in the Supply Chain. Long Range Planning: 27 (1): 72–83.

McAllister C (2006) Requirements Determination of Information Systems: User and Developer Perceptions of Factors Contributed to Misunderstandings. Doctoral dissertation, Capella University, Minnesota, USA.

McEvily SK, Das S, McCabe K (2000) Avoiding competence substitution through knowledge sharing. Academy of Management Review 25(2): 2294–311.

McGrath M (2000) Product Strategy for High Technology Companies. 2nd ed. New York, McGraw-Hill.

Millson MR, Raj SP & Wilemon D (1992) A survey of major approaches for Accelerating new product development. Journal of Product Innovation Management 9(1): 53–69.

Minbaeva D (2007) Knowledge Transfer in Multinational Corporations. Management International Review 47(4): 567–594.

Mirani R (2006) Client-vendor relationships in offshore applications development: An evolutionary framework. Information Resources Management Journal 19(4): 72–86.

Monczka R, Handfield R, Schannell T, Ragatz G & Frayer D (2000) New Product Development – Strategies for Supplier Integration. USA: American Society for Quality.

Morris LJ & Stauffer LA (1994) A design taxonomy for eliciting customer requirements. In: Proceeding of the 16th Annual Conference on Computers and Industrial Engineering. Pergamon, New York.

Moskalev SA & Swensen RB (2007) Joint ventures around the globe from 1990–2000: Forms, types, industries, countries and ownership patterns. Review of Financial Economics 16(2007): 29–67.

Mottonen M, Harkonen J, Belt P, Haapasalo H & Simila J (2009) Managerial view on design for manufacturing. Industrial Management & Data Systems 109(6): 859 – 872

Mowery D, Oxley J & Silverman B (1996) Strategic alliances and interfirm knowledge transfer. Strategic Management Journal 17(S2): 77–91.

Mueller-Prothmann T & Finke I (2004) Social Network Analysis as a Method for Expert Localisation and Sustainable Knowledge Transfer. Journal of Universal Computer Science 10(6): 691–701.

Nair B (2009) Requirements Engineering. URI: http://www. slideshare.net/ BenoyRNair/ requirements-engineering. Cited 2011/11/15.

Naz H & Khokhar N (2009) Critical Requirements Engineering Issues and their Solution. In: Proceeding of the ICCMS 2009. Macau, China.

Nitecki JZ (1993) Metalibrarianship: A Model For Intellectual Foundations of Library Information Science. URI: http://twu.edu/library/Nitecki/Metalibrarianship/. Volume 1 of The Nitecki Trilogy. Cited 2011/12/15.

Nobelius D and Trygg L (2002) Stop chasing the Front End process — Management of the early phases in product development projects. International Journal of Project Management 20(5): 331–340.

Page 114: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

112

Nonaka I (1994) A Dynamic Theory of Organizational Knowledge. Organization Science 5(1): 4–37.

Nonaka I & Takeuchi H (1995) The Knowledge-Creating Company: How Japanese Companies Create Dynamics of Innovation. New York, Oxford University Press.

Novins P & Armstrong R (1998) Choosing your spots for knowledge management. Perspectives on Business Innovation 1: 45–54.

OCED (2003) OCED Science, Technology and Industry Scoreboard 2003. OCED Publishing. Doi: 10.1787/sti_scoreboard-2003-en.

O’Dell C & Grayson CJ (1999) Knowledge transfer: discover your value proposition. Strategy & Leadership 27(2): 10–15.

Oh J & Rhee SK (2010) Influences of supplier capabilities and collaboration in new car development on competitive advantage of carmakers. Management Decision 48(5): 756–774.

Ohmae K (1989) The global logic of strategic alliances. Harvard Business Review 67(2): 143–154.

Oppenheim C, Stenson J & Wilson R (2004) Studies on Information as an Asset I: Definitions. Journal of Information Science 29(3): 159–166.

Odor FN (2010) New service development: Strategy and process in the hospitality sector in Kenya. In: Proceeding of the 19th EDAMBA. Soreze, France.

Osterloh M & Frey BS (2000) Motivation, Knowledge Transfer, and Organizational Form. Organization Science 11(5): 538–550.

Osterwalder, A. (2004) The Business Model Ontology, A Propositional in a design science approach. Univertsite de Lausanne Ecole des Hautes Etudes Commerciales.

Parker H (2000) Interfirm collaboration and the new product development process. Industrial Management + Data Systems 100(6): 255–260.

Parviainen P, Hulkko H, Kääriäinen J, Takalo J & Tihinen M (2003) Requirements Engineering, Inventory of Technologies. Espoo, Helsinki, VTT Publications.

Patton MQ (2002) Qualitative evaluation and research methods. 3rd ed. Thousand Oaks, California, Sage Publications.

Petersen KJ, Handfield RB & Ragatz GL (2005) Supplier integration into new product development: coordinating product, process and supply chain design. Journal of Operations Management 23(3–4): 371–388.

Petersen KJ, Handfield RB & Ragatz GL (2003) A Model of Supplier Integration into New Product Development. Journal of Product Innovation Management 20(4): 284–299.

Pilat L & Kaindl H (2011) A knowledge management perspective of requirements engineering, in Research Challenges in Information Science (RCIS). In: Proceeding of the Fifth International Conference. Gosier: 1–12.

Pfleeger SL (1998) Software Engineering – Theory and Practice. Upper Saddle River, NJ, Prentice Hall.

Pohl K (2010) Requirements Engineering - Fundamentals, Principles, and Techniques. New York, Springer.

Pohl K (1996) Process-Centered Requirements Engineering. Somerset, UK, Research studio press.

Page 115: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

113

Polanyi M (1962) Personal Knowledge: Towards a Post-critical Philosophy. Chicago, University of Chicago Press.

Poppo L & Zenger T (1998) Testing alternative theories of the firm: Transaction cost, knowledge based and measurement explanations for make-or-buy decisions in information services. Strategic Management Journal 19(9): 853–877.

Postrel S (2002) Islands of Shared Knowledge: Specialization and Mutual Understanding in Problem-Solving Teams. Organization Science 13(3): 303–320.

Probst G, Raub S & Romhardt K (2000) Managing Knowledge. London, Wiley. Quigley EJ & Debons A (1999) Interrogative theory of information and knowledge. In:

Proceeding of the 1999 ACM SIGCPR Conference on Computer Personnel Research. New Orleans, Louisiana, USA.

Raatikainen M, Mannisto T, Tommila T & Valkonen J (2011) Challenges of requirements engineering — A case study in nuclear energy domain. In: Proceeding of the 19th IEEE International on Requirements Engineering Conference (RE). Trento, Italy: 253–258.

Ragatz G, Handfield R & Scannell T (1997) Success factors for integrating suppliers into new product development. Journal of Product Innovation Management 14(3): 190–202.

Reid SE & Brentani UD (2004) The fuzzy front end of new product development for discontinuous innovations: A theoretical model. Journal of Product Innovation Management 21(3): 170–184.

Riege AM (2003) Validity and reliability tests in case study research: a literature review with “hands-on” applications for each research phase. Qualitative Market Research: An International Journal 6(2): 75 – 86.

Robertson S & Robertson J (2006) Mastering the requirements process. 2nd ed. New York, Addison Wesley.

Rombach HD (1990) Software Specifications: A Framework. SEI Curriculum Module SEI-CM -11-2.1, Software Engineering Institute, Carnegie Mellon University, Pittsburgh.

Sarker S, Sarker S, Nicholson D & Joshi K (2005) Knowledge transfer in virtual systems development teams: An exploratory study of four key enablers. IEEE Transactions on Professional Communication 48(2): 201–218.

Saunders M, Lewis P & Thornhill A (2007) Research Methods for Business Students. 4th ed. Harlow, UK. Prentice Hall.

Schotter A & Bontis N (2009) Intra-organizational knowledge exchange: An examination of reverse capability transfer in multinational corporations. Journal of Intellectual Capital 10(1): 149 – 164.

Schwaber K (2004) Agile Software Development with Scrum. Redmond, WA, Microsoft Press.

Schwaber K (1995) Scrum development process. In: Proceeding of OOPSLA’95 workshop on business object design and implementation. Springer-Verlag.

Schwartzman HB (1993) Ethnography in Organizations: Qualitative Research Methods. Volume 27. Newbury Park, California, Sage Publications.

Page 116: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

114

Scott J (1999) Social Network Analysis: A Handbook. 2nd ed. London, Sage. Seppälä T (2001) Buyer–supplier relationships and sourcing of strategic components.

Doctoral dissertation. Turku School of Economics and Business Administration, Turku, Finland.

Shafer S, Smith H & Linder J (2005) The power of business models. Business horizons 48(3): 199–207.

Shekar A (2007) An Innovative model of service development: A progress guide for service managers. The Innovation Journal: The Public Sector Innovation Journal, 12(1): 1–18.

Simonin BL (1999) Ambiguity and the process of knowledge transfer in strategic alliances. Strategic Management Journal 20(7): 595–623.

Simonin BL (1997) The Importance of Collaborative Know-How: An Empirical Test of the Learning Organization. Academy of Management Journal 40(5): 1150–1174.

Sivadas E & Dwyer F (2000) An examination of organizational factors influencing new product success in internal and alliance-based processes. Journal of Marketing 64(1): 31–49.

Small C & Sage A (2006) Knowledge management and knowledge sharing: a review. Information Knowledge Systems Management 5(3): 153–169.

Smeds R, Hsho P & Forssen M (2001) Implementing knowledge into action in organizations: simulation games for successful process innovation. In Pantzar E, Savolainen R & Tynjälä P (eds.): In Search for a Human-Centered Information Society, Reports of the Information Research Programme of the Academy of Finland. Tampere University Press, Finland: 171–194.

Soini J (2007) An approach to knowledge transfer in software measurement. Informatica 31(4): 437–446.

Sommerville I (2006) Software Engineering. 8th ed. Harlow, UK. Addison Wesley. Sommerville I & Sawyer P (1997) Viewpoints: Principles, problems and a practical

approach to requirements engineering. Annals of Software Engineering 3: 101–130. Song M & Di Benedetto C (2008) Supplier's involvement and success of radical new

product development in new ventures. Journal of Operations Management 26(1): 1–22. Spencer JW (2003) Firms' knowledge-sharing strategies in the global innovation system:

empirical evidence from the flat panel display industry. Strategic Management Journal 24(3): 217–233.

Spender JC (1996) organizational knowledge, learning, and memory: three concepts in search of a theory. Journal of Organizational Change Management 9(1): 63–78.

Squicciarini M & Loikkanen T (2008) Going Global: The Challenges for Knowledge-based Economies. MPRA Paper 9663, University Library of Munich, Germany.

Starbuck W (1992) Learning by knowledge-intensive firms. Journal of Management Studies 29(6): 713–740.

Stevens R, Brook P, Jackson K & Arnold S (1998) System engineering – coping with complexity. London, Prentice Hall.

Streeter CL & Gillespie DF (1992) Social Network Analysis. Journal of Social Service Research 16(1/2): 201–222.

Page 117: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

115

Sun PY & Scott JL (2005) An Investigation of Barriers to Knowledge Transfer. Journal of Knowledge Management 9(2): 75–90.

Sverlinger P-O (2000) Managing Knowledge in Professional Service Organizations. Doctoral thesis, Department of Service management, University of Technology, Gothenburg, Sweden.

Szulanski G (2003) Sticky Knowledge: Barriers to Knowing in the Firm. London, SAGE Publications.

Szulanski G (2000) The process of knowledge transfer: a diachronic analysis of stickiness. Organizational Behavior and Human Decision Processes 82(1): 9–27.

Szulanski G (1996) Exploring internal stickiness: impediments to the transfer of best practice with in the firm. Strategic Management Journal 17(1): 27–43.

Szulanski G, Cappetta R & Jensen JR (2004) When and How Trustworthiness Matters: Knowledge Transfer and the Moderating Effect of Causal Ambiguity. Organizational Science 15(5): 600–613.

Tatikonda MV & Zeithaml VA (2002) Managing the new service development process: Multi-disciplinary literature synthesis and directions for future research. In Boone & Ganeshan (eds.): New directions in supply-chain management: Technology, strategy and implementation, New York, American Management Association: 201–233.

Teece DJ (1998) Research directions for knowledge management. California Management Review 40(3): 89–292.

Timbrell G, Andrews N & Gable G (2001) Impediments to Inter-firm transfer of best practice in an Enterprise Systems Context. Australian Journal of Information Systems 9(1): 116–125.

Tsai W (2002) Social Structure of Coopetition within a Multiunit Organization: Coordination, Competition, and Intra-organizational Knowledge Sharing. Organizational Science 13(2): 179–190.

Tsai W & Ghoshal S (1998) Social capital and value creation: the role of intrafirm networks. The Academic of Management Journal 41(4): 464–471.

Tuomi I (1999) Data is more than knowledge: implications of the reversed knowledge hierarchy to knowledge management and organizational memory. In: Proceeding of the 32nd Hawaii International Conference on Systems Sciences. Hawaii, USA.

Ulrich K & Eppinger S (2008) Product Design and Development. New York, McGraw-Hill.

Un CA, Cuervo-Cazurra A & Asakawa K (2010) R&D Collaborations and Product Innovation. Journal of Product Innovation Management 27(5): 673–689.

van der Spek R & Spijkervet A (1997) Knowledge Management: Dealing Intelligently with Knowledge. In Liebowitz J & Wilcox L (eds.): Knowledge Management and Its Intergrative Elements. New York: CRC Press.

van Wijk R, Jansen, JJP & Lyles MA (2008) Inter- and Intra-Organizational Knowledge Transfer: A Meta-Analytic Review and Assessment of Its Antecedents and Consequences. Journal of Management Studies 45(4): 830–853.

Page 118: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

116

Vicari S, Von Krogh G, Roos J & Mahnke U (1996) Knowledge Creation Through Cooperative Experimentation. In Von Krogh G & Roos J (eds.): Managing Knowledge: perspectives on cooperation and competition. London, SAGE Publications: 184–202.

Voss C, Tsikriktsis N & Frohlich M (2002) Case research in operations management. International Journal of Operations & Production Management 22(2): 195–219.

Wagner SM & Hoegl M (2006) Involving suppliers in product development: Insights from R&D directors and project managers. Industrial Marketing Management 35(8): 936–943

Wang P, Tong TW & Koh C-P (2004) An integrated model of knowledge transfer from MNC parent to China subsidiary. Journal of World Business 39(2): 168–182.

Wasserman S & Faust K (1997) Social Network Analysis: Methods and Applications. New York, Cambridge University Press.

Westfall L (2006) Software Requirements Engineering: What, Why, Who, When and How. URI: http://www.westfallteam.com/Software_Engineering_Process_Paper_&_ References.htm. Cited 2011/8/28.

Webster’s Ninth New Collegiate Dictionary (1989) editor in chief, Frederick C. Wyoming, United States, Mish, Merriam-Webster.

Wiegers K (2003) Software Requirements. 2nd ed. Redmond, Microsoft Press. Wiig K (1993) Knowledge Management Foundations: Thinking about Thinking – How

People and Organizations Create, Represent and use Knowledge. Arlington, TX, Schema Press.

Wilson DT (1995) An integrated model of buyer–seller relationships. Journal of the Academy of Marketing Science 23(4): 335–345.

Winter SG (1987) Knowledge and competence as strategic assets. In Teece DJ (ed.): The Competitive Challenge: Strategies for Industrial Innovation and Renewal, Cambridge, Ballinger: 159–184.

Wynstra F, van Weele A & Weggeman M (2001) Managing supplier involvement in product development: three critical issues. European Management Journal 19(2): 157–167.

Xu Q & Ma Q (2008) Determinants of ERP implementation knowledge transfer. Information & Management 45(8): 528–538.

Yang SB & Kim YG (2007) Inter-organizational knowledge transfer in the buyer–supplier relationship: a buyer’s perspective. In: Proceeding of the 40th Hawaii International Conference on System Sciences. Hawaii, USA: 188c.

Yin RK (2009) Case Study Research: Design and Methods. 4th ed. California, Sage Publications.

Zagajsek B, Separovic K & Car Z (2007) Requirements Management Process Model for Software Development Based on Legacy System Functionalities. In: Proceeding of the 9th International Conference on telecommunications (ConTel 2007). Zagreb, Croatia: 115–122.

Zahay D, Griffin A & Fredericks E (2004) Sources, uses, and forms of data in the new product development process. Industrial Marketing Management 33(7): 657–666.

Page 119: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

117

Zahra SA & Bogner WC (2000) Technology strategy and software new ventures’ performance: exploring the moderating effect of the competitive environment. Journal of Business Venturing 15(2): 135–173.

Zander U & Kogut B (1995) Knowledge and the speed of the transfer and imitation of organizational capabilities: an empirical test. Organization Science 6(1): 76–92.

Zhang Q & Doll WJ (2001) The fuzzy front end and success of new product development: A causal model. European Journal of Innovation Management 4(2): 95–112.

Zirpoli F & Camuffo A (2009) Product architecture, inter-firm vertical coordination and knowledge partitioning in the auto industry. European Management Review 6(4): 250–264.

Page 120: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

118

Page 121: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

119

Original publications

I Distanont A, Haapasalo H, Rassameethes B & Lin B (2011) Developing new product through collaboration in high-tech enterprises. International Journal of Management and Enterprise Development 10(1): 51–71.

II Distanont A, Haapasalo H, Rassameethes B & Lin B (2012) Knowledge transfer pattern in collaborative product development. International Journal of Intercultural Information Management 3(1): 59–81.

III Distanont A, Haapasalo H, Kamolvej T & Meeampol S (in press) Interaction patterns in collaborative product development (CPD). International Journal of Synergy and Research.

IV Distanont A, Haapasalo H, Vaananen M & Lehto J (in press) The engagement between knowledge transfer and requirements engineering. International Journal of Management, Knowledge and Learning.

V Distanont A, Haapasalo H & Vaananen M (in press) Organising knowledge transfer in requirements engineering over organisational interfaces. International Journal of Innovation and Learning.

Reprinted with permission from Inderscience (I,II,V), (III), IJSR (III), and IJMKL

(IV).

Original publications are not included in the electronic version of the dissertation.

Page 122: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

120

Page 123: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

A C T A U N I V E R S I T A T I S O U L U E N S I S

Book orders:Granum: Virtual book storehttp://granum.uta.fi/granum/

S E R I E S C T E C H N I C A

424. Macagnano, Davide (2012) Multitarget localization and tracking : Active andpassive solutions

425. Körkkö, Mika (2012) On the analysis of ink content in recycled pulps

426. Kukka, Hannu (2012) Case studies in human information behaviour in smarturban spaces

427. Koivukangas, Tapani (2012) Methods for determination of the accuracy of surgicalguidance devices : A study in the region of neurosurgical interest

428. Landaburu-Aguirre, Junkal (2012) Micellar-enhanced ultrafiltration for theremoval of heavy metals from phosphorous-rich wastewaters : From end-of-pipeto clean technology

429. Myllymäki, Sami (2012) Capacitive antenna sensor for user proximity recognition

430. Jansson, Jussi-Pekka (2012) A stabilized multi-channel CMOS time-to-digitalconverter based on a low frequency reference

431. Soini, Jaakko (2012) Effects of environmental variations in Escherichia colifermentations

432. Wang, Meng (2012) Polymer integrated Young interferometers for label-freebiosensing applications

433. Halunen, Kimmo (2012) Hash function security : Cryptanalysis of the VerySmooth Hash and multicollisions in generalised iterated hash functions

434. Destino, Giuseppe (2012) Positioning in Wireless Networks : Non-cooperativeand cooperative algorithms

435. Kreku, Jari (2012) Early-phase performance evaluation of computer systems usingworkload models and SystemC

436. Ossiannilsson, Ebba (2012) Benchmarking e-learning in higher education : Lessonslearned from international projects

437. Pouttu, Ari (2012) Performance Analysis of mMCSK-mMFSK modulation variantswith comparative discussion

438. Kupiainen, Laura (2012) Dilute acid catalysed hydrolysis of cellulose – extensionto formic acid

439. Kurtti, Sami (2012) Integrated receiver channel and timing discrimination circuitsfor a pulsed time-of-flight laser rangefinder

C440etukansi.kesken.fm Page 2 Wednesday, December 12, 2012 1:20 PM

Page 124: OULU 2012 ACTAjultika.oulu.fi/files/isbn9789526200545.pdf · each knowledge type needs to be transferred through the suitable transfer channel at the right time. ... tulee siirtää

ABCDEFG

UNIVERS ITY OF OULU P.O.B . 7500 F I -90014 UNIVERS ITY OF OULU F INLAND

A C T A U N I V E R S I T A T I S O U L U E N S I S

S E R I E S E D I T O R S

SCIENTIAE RERUM NATURALIUM

HUMANIORA

TECHNICA

MEDICA

SCIENTIAE RERUM SOCIALIUM

SCRIPTA ACADEMICA

OECONOMICA

EDITOR IN CHIEF

PUBLICATIONS EDITOR

Senior Assistant Jorma Arhippainen

University Lecturer Santeri Palviainen

Professor Hannu Heusala

Professor Olli Vuolteenaho

University Lecturer Hannu Heikkinen

Director Sinikka Eskelinen

Professor Jari Juga

Professor Olli Vuolteenaho

Publications Editor Kirsti Nurkkala

ISBN 978-952-62-0053-8 (Paperback)ISBN 978-952-62-0054-5 (PDF)ISSN 0355-3213 (Print)ISSN 1796-2226 (Online)

U N I V E R S I TAT I S O U L U E N S I SACTAC

TECHNICA

U N I V E R S I TAT I S O U L U E N S I SACTAC

TECHNICA

OULU 2012

C 440

Anyanitha Distanont

KNOWLEDGE TRANSFERIN REQUIREMENTS ENGINEERINGIN COLLABORATIVE PRODUCT DEVELOPMENT

UNIVERSITY OF OULU GRADUATE SCHOOL;UNIVERSITY OF OULU,FACULTY OF TECHNOLOGY,DEPARTMENT OF INDUSTRIAL ENGINEERING AND MANAGEMENT

C 440

ACTA

Anyanitha D

istanontC440etukansi.kesken.fm Page 1 Wednesday, December 12, 2012 1:20 PM