Management of Innovation and Knowledge Integration in Product Development Projects
Fredrik TellKITE Research Group
Department of Management and EngineeringLinköping University
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