Management of Innovation and Knowledge Integration in Product Development Projects

Fredrik TellKITE Research Group

Department of Management and EngineeringLinköping University

Swedenfredrik.tell@liu.se

Presentation outline

• Knowledge Integration and Innovation: The problem

• Integrating Knowledge in Complex ProductDevelopment Projects

Why knowledge integration and innovation?

• Knowledge specialization increasingly important, as firms are increasingly multi-technological (Granstrandet al 1997; Brusoni et al, 2001)

• Knowledge integration is difficult (Dougherty, 1992; Hoopes and Postrel, 1999; Lindkvist, 2005)

• Knowledge integration important for performance (Piscitello, 2004; Brusoni et al, 2005; Nesta and Saviotti, 2006)

• Innovations as “new combinations” (Schumpeter, 1942) require integrative capabilities (Henderson, 1994)

What firms do

• Firms produce products and services• To produce things firms need capabilities• To be capable of producing, firms need to

integrate knowledge• Knowledge integration takes place under

conditions of bounded rationality

Conceptions of Firms

Production Exchange

Unboundedrationality

Boundedrationality

EvolutionaryEconomics

TextbookOrthodoxy

Working paperOrthodoxy

Transaction CostEconomics

(Winter, 1988)

Governance/Organizational problem

• Problem of co-operation– Incentive alignment

• Problem of co-ordination– Knowledge integration

How to achieve cooperation?

• Firm as a nexus of contracts that unify property and decision rights

• Incomplete contracts (firms as failed markets)

– Hierarchy – authority relationships– Reward sharing schemes (incentives)

“The key idea is to provide as focused, intense incentives as possible within the constraints implied by the corporate form and the interdepen-dencies that it both creates and is meant to control. The key architectural elements involve redrawing the vertical and horizontal boundaries of the firm to increase strategic focus; creating relatively small subunits within the organization in which significant decision rights are lodged […].

(John Roberts, The Modern Firm, 2004: 180)

Co-ordination problem

• How to integrate different knowledge bases for efficient production?

“Coordination means, at a minimum, that all the needed tasks are completed without pointless duplication. Better yet, it seeks to ensure that the tasks are done efficiently, by the right people, in the right way, and at the right time and place. Ultimately, full coordination also requires that the tasks undertaken are the right ones.”

(John Roberts, The Modern Firm, 2004: 75)

How do firms produce new things?

• Through new combinations, Schumpeter toldus…

• New combinations require integration of existing knowledge as well as generation of new knowledge

The problem of knowledge integration

• Knowledge specialization requires integration• Knowledge complementarities• Knowledge transfer is not always efficient

(Grant, 1996; Schmickl & Kieser, 2008)

“If the traditional problem of the division of labor is to trade off the superior task efficiency of specialization against its inferior coordination properties, the fundamental tension in the division of knowledge is between the superior learning efficiency of specialization and its inferior integration properties.”

(Postrel, 2002: 306)

Achieving knowledge integration

• Knowledge Integration mechanisms:– Hierarchy, rules, prices, property rights sharing,

communication networks, knowledge integrators, teams, communities (Grandori, 2001)

– Rules and directives, sequencing, routines, group problem solving (Grant, 1996)

– Tacit experience accumulation, articulation, codification (Zollo and Winter, 2002)

Organizing for innovation

• New product development projects example of knowledge integration in innovative (although not always radical) settings

• How is knowledge integrated?• Knowledge integration in the development of complex

products under time constraints (Lindkvist, Söderlund and Tell 1998)

• Knowledge integration and near decomposability in productplatform projects (Yakob and Tell, 2007; 2009)

• Integration of distributed knowledge in new productdevelopment projects (Enberg, Lindkvist and Tell, 2006; 2010)

Projects and knowledge integration

• Projects as a separation strategy• Projects as a device for dealing with non-

repetitive tasks• Projects are made up of temporary

constellations of people

NPD in telecoms

• How is knowledge integrated in large and complex development projects?

• Concurrent engineering in NPD projects: Now (in operation 2006) and then (in operation 1994) in the telecom industry.

• Large development projects (>100 engineers)• Follow up-projects on major breakthrough

technologies• Researched by retrospective, interview-based,

qualitative case-studies

1990s NPD: Post GSM

• Digital cellular telephony system for a new important customer

• New standard partly based on GSM• Software and hardware• Half development time of GSM• 1 country, >100 engineers, 2 years

Lindkvist, L., J. Söderlund and F. Tell (1998), Managing Product Development Projects – On the Significance of Fountains and Deadlines, Organization Studies, 19(6): 931-951

Concurrent engineering

Concept

Design

Test & Verif.

Time

Installation

Analysis

Type of error problematic(Levinthal & March, 1993)

error detection

error diagnostics

Type of complexity (Perrow, 1970)

analyzable systemic

Schedulinglogic

Couplinglogic

Separatinglogic

Semi-couplinglogic

Implications for knowledge integration

• High complexity but error detection rather than error diagnosis – Tightly coupled projects

• Tight knowledge integration– Practicing the processes– Solving problems due to interaction effects among units– Continuous feedback – little buffers– Less ‘work breakdown structure’ oriented– Arenas

• Systems emergency ward• Daily meetings• Video/telephone conferencing

– Combination of hierarchical and network structures

Knowledge integration in complex productproduct platforms

• How do organizations solve complexproblems in product development?

• Example of platforms

Yakob, R and F. Tell (2007), Managing Near Decomposability in Complex Platform Development Projects, International Journal of Technology Intelligence and Planning, 3(4): 387-407

Yakob, R. and F. Tell (2009), Detecting Errors Early: Management of problem-solving in product platform projects, in: Gawer, A. (ed.), Platforms, Markets and Innovation, Cheltenham, UK and Northampton, MA, US: Edward Elgar

Telecoms in the 2000s: Post 3G platform

• Leading global telecommunications firm - develops, produces, supplies, and installs telecommunications systems

• n th version of third generation cellular telephone system

• Run partly in parallel with version n-1 and n+1 version

• Software platform (hardware negligible)

• 5 countries, > 200 engineers, 24 months

Methodology

N=7Of which - Operational (engineering) level

N=3Of which - Middle Management level

N=3Of which - Top management level

N=13- Project Organization

- Permanent Organization

Focus of empirical material collection (interviews)

X- Documentation

N=13- InterviewsEmpirical Material Collection Techniques

Problem-solvingAnalytical Unit

ComplexityExplanatory Unit

Platform Development

ProcessObservational Unit

X- RetrospectiveCase timeline

X- Case StudyResearch Method

Research problem

• Previous research particularly concerned with outcomes of platform development approaches ratherthan the process itself

(e.g. Krishnan and Gupta, 2001; Muffato and Roveda, 2000; Meyer and Lehnerd, 1997)

• Previous research primarily dealt with complexity in platform development by modular approaches, assuming perfect decomposability

(e.g., Ethiraj and Levinthal, 2004; Baldwin and Clark, 2000; Ericsson and Erixon, 1999)

Types of problems

• Low interaction problems– Fully decomposable systems

• Moderate interaction problems– Nearly decomposable systems

• High interaction problems– Non-decomposable systems

(Nickerson & Zenger, 2004)

Understanding Complex platform projects as nearly decomposable systems

“(1) In a nearly decomposable system the short-run behaviour of each component sub-system is approximately independent of the short run behaviour of the other components; (2) in the longrun the behaviour of components depends in only an aggregate way on the behaviour of the other components” (Simon, 1996: 198)

“While decomposing a problem is necessary in order to reduce the dimension of the search space, it also shapes and constrains a search process to a specific sub-space of possible solutions thus making it possible for optimal solutions not to be ever generated and for systems to be locked into sub-optimal solutions” (Marengo, Pasquali and Valente, 2005: 3)

Perceived problems with previous ways of working

• Quality not up to standard• Difficulties in adapting to emerging

objectives and new specifications• Time delays

Developing telecom platforms in work packages

• Starting early by defining small work packages (WP)

• Work out a genealogy of the project

• Set up interdisciplinary teams working with each package (teams of 10-15)

• Each WP is an entity in the anatomy (60-70 WP)

• Fairly brief “slots” for delivery from WP to systems integration (second weekly build)

• Continuous integration enabled by “build” environment tool

Ways of Working

Design Base

WP 1 WP 2

Latest System Version

WP 3 WP 4 WP 5

Latest System Version

WP 6 WP 7 WP 8

Final System Version

Previously This project

Design Base

WP

WP

WP

WP

Final System Version

WP 1 WP 4 WP 2+3

WP 5+6

The Anatomy of a project

Design BaseDesign Base

WorkPackage

Integration Dependency

Shipment (Delivery to customer)

Shipment 1

Shipment 2

Shipment 3

Development Pattern

Understanding product development as problem-solving

• Directional search• Analytical search

Directional search processes

(experiential, on-line, local)• Actual experience of how action and outcome interlink, problems

that cause a gap between actual and potential performance canbe discovered (Pisano,1994).

• Attempt to bridge the lack of prior knowledge of how action and outcome interlink by independently observing how performance reacts to changes. Incremental approach towards problem-solvingwhere experience of the resulting performance of the changesmade is an important input into the subsequent choice made.

• Assumes that whenever a problem is encountered and taken on, the problem can be divided into several constituent parts; eachpart worked on independently; and the contributing results of this action in finding a solution to the problem observed independentlyfrom other parts.

• Feed-back (from errors) the central process (Gavetti & Levinthal, 2000)

Analytical search processes

(cognitive, heuriustic, scientific)• Understanding a complex problem and analytically determine

action – outcome linkages, problem-solvers need to revert to finding good enough rather than optimized solutions to problems

• Drawing upon rough representation of complexity and problems faced efforts towards establishing what type of solutions are sought for can be made.

• Analyticalproblem-solving search processes are concerned with attempts to cognitively evaluateprobable consequences of choices taken and identify useless directions of searchbeforehand and providing a glimpse of the possible (Fleming and Sorensen, 2004)

• Feed-forward (to problems) the central process (Gavetti & Levinthal, 2000)

Managing near decomposability

Search process• System aggregation and knowledge integration• Decomposition and (re)composition (cf. modularity)• Learning dynamics of feed-back and feed-forward

Aggregate/

Design Base Component

Development

Compose

Feed-back

Exit Point(s)

Anatomical

Decomposition

Decompose

Feed-forward

Automotives: solving errors but not problems

Aggregate/

Design Base Component

Development

Compose

Feed-back

Exit Point(s)

Anatomical

Decomposition

Decompose

Feed-forward

Integration of distributed knowledge: The stacker NPD project

• Incremental, 1 country, 13 engineers, 2 years• Not much of a shared goal• Project members were not working tightly together

– Located in different departments– Little communication– Met primarily at project meetings – but not in conducting

their work• Knowledge did not seem to be shared • How did knowledge integration take place?

Enberg, C., L. Lindkvist and F. Tell (2006), Exploring the Dynamics of Knowledge Integration: Acting and Interacting in Project Teams, Management Learning, 37(2): 143-165

Traditional KM view • Codified knowledge for

simple tasks and standardized products

• Tacit knowledge for advanced tasks and customized solutions

(e.g., Grant 1996; Hansen et al1999;)

Alternative view• Task features and knowledge

integration

• Learning investment function

• Frequency

• Homogeneity

• Causal ambiguity (complexity)

(Zollo and Winter, 2002)

Articulation/Codification

Articulation/Codification

Articulation/Codification

Integrating Knowledge

Learning typologies, outcomes and economic benefits Learning Processes

Experience accumulation

Knowledge articulation Knowledge codification

Learning typology

Learning by doing

Learning by using

Learning by reflecting Learning by thinking Learning by discussing Learning by confronting

Learning by writing and re-writing

Learning by implementing

Learning by replicating

Learning by adapting

Outcome

Local experts and experiential knowledge in individuals (e.g. subject matter expert)

Symbolic representations and communication

Improved understanding of action-performance relation (predictive knowledge)

Codified manuals, procedures (e.g. project management process)

Economic

benefit

Economics of specialisation

Economics of co-ordination

Economics of information (diffusion, reuse of information)

Prencipe, A. and F. Tell (2001), Inter-project learning: processes and outcomes of knowledge codification in project-based firms, Research Policy, 30/9: 1373-1394

A process typology

The Stacker project

• Incremental, 1 country, 13 engineers, 2 years• Not much of a shared goal• Project members were not working tightly together

– Located in different departments– Little communication– Met primarily at project meetings – but not in conducting

their work• Knowledge did not seem to be shared • How did knowledge integration take place?

Methodology

Development of the iterative model and knowledge integration framework.

Observations of eight project meetings.

Informal discussions.

Phase three

The notion of teamwork, the role of shared goals and knowledge sharing.

Interviews with the project manager and all project members.

Phase two

The character of meetings and project interaction.

Observations of eight project meetings.

Informal discussions.

Phase one

Conceptual issuesData collection

The Stacker case

MartinProject manager

Located at the development departmentInternal coursesTenure: 17 years

HarryDesign engineer consultant

Located at the development departmentVocational training

BillDesign engineer consultant

Located at the development departmentBSc in engineering

AlbertOrder structure builder

Manufacturing departmentCo-located with Harry and Bill

No formal educationTenure: 40 years

CharlesOrder structure builder

Manufacturing departmentNo formal education

Tenure: 17 yearsTom

Order and administrationSecondary school certificate

Tenure: 13 years

StevenManufacturing, tripods and chassis

(sub-group at the manufacturing department)Internal coursesTenure: 20 years

RichardManufacturing, walkie

(sub-group at the manufacturing department)BSc in engineering

Tenure: 2 years

PaulTechnical support and field testing

(sub-group at the development department)Vocational trainingTenure: 30 years

AnthonyQuality and standards

(sub-group at the development department)BSc in engineering

Tenure: 4 years

HenryMarketing

No formal educationTenure: 30 years

SarahResponsible for technical requirements

Development departmentMSc in engineering

Tenure: 2 yearsJohnElectro-design

Located at the IT departmentVocational training Tenure: 25 years

An iterative model of knowledge integration

Parameter input

Experience sharing

Ad hoc problem solving

Contribution

Representation

Subordination

The Product

Interacting

Acting

(Enberg, Lindkvist & Tell, 2006)

Frequency High Low High Homogeneity High Low High Complexity Low High High Knowledge integration mechanism

Experience accumulation

Articulation/ Codification

Iterative model

A more complex case

Steam TurbinesEnberg, C., L. Lindkvist and F. Tell (2010), Knowledge integration at the edge of technology: On teamwork and complexity in new turbine development, forthcoming in International Journal of Project Management

Introduction

• Product development projects call for integrating specializedknowledge bases

• Literature: Tendency to treat all projects as similar (Shenhar2001, Sauser 2009)

• Literature: Current frameworks best suited for ’simple’ situations (Carlile & Rebentisch, 2003)

• Purpose: Explore team-based knowledge integration in a highlycomplex project – the Turbine project

Methodology

• A case study, inspired by ethnography

• One person co-located with the team during one year

• Observations and informal discussions on a dailybasis, formaI interviews (15), attending meetings(35), access to documents, data bases, intranet, etc

• Workshop at PowerCo based on the findings

The Turbine Project

• 50/60 Hz Low Pressure (LP) steam turbine with increased efficiency, an increased exhaust area and a blading cost increase of less than 15% …”… at the leading edge of technology”

• Strongly specialized members

• Difficult trade-off between thermal efficiency and low cost, and aerodynamic efficiency and mechanical integrity

• Prototyping not possible. Only partly validated tools

Teamwork in the Turbine project

• A process of iteration between a small group of experienced members (EM) and members with less experience (LE)

• EM group had a major integrative role and understood each other well• ”If I make a calculation, if the mean is 300, that means a lot of things to me and I

know that if it’s Valentin who has worked with it, then I know what he did and the process is clear. If I told him just to make [a certain kind of calculation, explainedonly briefly] then I know that he knows that I mean a stress calculation 2D and frequency calculation 2D for the system, and that means a process. So there are a lot of things which are unsaid.” (Experienced project member, MI)

• LE responsible for assigned tasks. LE felt uneasy about their role and felt’decoupled’ from the project”Because I think that they exchange a lot of useful information … when they are talking about numbers but I don’t understand what it is about, the pressure clearance or whatever.”(Less experienced project member, MI)

• Yet, it was one team and the project was concluded successfully

Experienced vs less experienced team members

Plan

Feedback

Plan

Experienced project members

Communication

Interaction

Less exp.

Less exp.

Less exp.

Less exp.

Team-based knowledge integration

• Knowledge integration (KI) (Grant 1996)• Rules, routines, etc in ’simple’ contexts• Group problem-solving in difficult contexts

• High differentiation/High complexity calls for ’teams’(Grandori 2001)

• Grant/Grandori : This implies costly ’communication-intensive’ interaction

KnowledgeIntegrators

Project Teams

CommunicationNetworks

Communitiesof Practice

High

Low

HighLow

Degree of Knowledge-Differentiation

Degree of Complexity

(Adapted from Grandori, 2001)

Need for fine-grained conceptions

• Much literatures deal with the link of mere existence of team-basedorganization and performance (Hoegl & Gemeunden, 2001)

• Hoegl & Gemeunden (2001) propose a Teamwork Quality (TWQ) construct with 6 facets:

Communication The possibility for all members to communicate formally and informally with all other members

Coordination The synchronization of individual contributions and the need to agree on work-down structures, schedules, budgets, and deliverables

Balance of member contributions

The possibility of all members to bring in their views and ideas, unrestrained by hierarchy and dominating others

Mutual support The existence of cooperative frames of mind and mutual respectEffort Everyone knowing and accepting the work norms concerning sufficient effortCohesion Team members’ sense of togetherness, belonging, and desire to remain on the team

In our view, this is useful to indicate the degree of team ’integration’ and ’segregation’

TWQ: LE and E team members

TWQ Facet Less experienced (LE) members Experienced (E) membersCommunication Members had limited possibilities to

communicate with other members of the project team

Members could easily communicate with all project team members

Coordination Members had little influence on work organization

Members had extensive influence on work organization

Balance of member contributions

Members were severely restrained regarding their opportunities of bringing in views and ideas

Members could freely expressed their views and ideas

Mutual support Members enjoyed respect primarily for carrying out assigned tasks

Members enjoyed respect for their knowledge and their contributions to problem-solving

Effort Members became somewhat de-motivated

Members were motivated and put in great effort

Cohesion Members felt ‘decoupled’, did not have a sense of being ‘full’ team members

Members felt integrated in the ’core’ of the team

Analysis

• Turbine project = Complex project and a SegregatedTeam

• LE members were not seen or treated as ’fullyintegrated equals’ of the team

• The Experienced Member group = the opposite result

Why a segregated team?• Many firms have a hierarchy of competences/knowledge• Team communication is very costly• Cutting inexperienced out of discussion may save

time and money

• However, this comes at another cost• Master-apprentice learning and long term competence development is

down-played

• Using a segregated team may well be efficient in the short term, butmust be complemented by other means to achieve long term sustainability

• Shows that a low level of team integration (using the TWQ construct by Hoegl & Gemuenden, 2001) may sometimes be beneficial

• Suggests that using a Segregated Team may be appropriate in complex contexts