Managing product development collaborations

1
Managing product development collaborations

• Pete Fraser
• Institute for Manufacturing, University of
  Cambridge
• Supported by EPSRC Grant GR/L63006

2
Overview

• The study
• Findings
• Key collaborative processes
• Workbook and tools
• Conclusions

3
Aims of the project

• Improve the understanding of the NPI process when
  significant development work is provided by new
  supplier / customer combinations
• Develop self-help workbook to assist in managing
  the processes of starting, operating and
  withdrawing from product development
  collaborations

Primary focus is on dynamics of individual
collaborations where at least one of the partners
is an SME
4
Methods
5
Collaborative advantage ...
Whatever the duration and objectives of
business alliances, being a good partner has
become a key corporate asset. I call it a
companys collaborative advantage. Kanter
(1994) if the capacity to collaborate is not
already a core competence in your organisation,
you had better get busy making it so. Doz and
Hamel (1998)
6
But ...
If there is one thing which all the disparate
literature on collaboration agrees upon it is
that collaboration is a very difficult thing to
make work. Dodgson (1993) e.g. Harrigan (1986)
reports a 45 success rate (survive more than 4
years) in a study of 895 joint ventures.
7
Collaboration and NPI Process
After Wheelwright Clark (1992), Rothwell
(1992, 1994), Biemans (1995)
8
Collaboration and NPI Process
Strategy, Ideas Knowledge
Fuzzy front end Concept development Specification
Design development
Technology development
Production
Sales distribution
Outsourcing Make v Buy
Agents distributors, access to global markets
Shared RD Alliance Pre-competitive
Design and development partnerships
Design Consultancy
Industry Standards Development Tools etc
Rapid prototyping etc
Machine shop Sheet metal PCB manufacture/assembly
Injection moulding etc
Promotion Logistics Agents
Technology expertise Specialist design skills
Industrial design etc
After Wheelwright Clark (1992), Rothwell
(1992, 1994), Biemans (1995)
9
Focus of this project
Strategy, Ideas Knowledge
Fuzzy front end Concept development Specification
Design development
Technology development
Production
Sales distribution
Outsourcing Make v Buy
Agents distributors, access to global markets
Shared RD Alliance Pre-competitive
Design and development partnerships
Design Consultancy
Industry Standards Development Tools etc
Rapid prototyping etc
Machine shop Sheet metal PCB manufacture/assembly
Injection moulding etc
Promotion Logistics Agents
Technology expertise Specialist design skills
Industrial design etc
After Wheelwright Clark (1992), Rothwell
(1992, 1994), Biemans (1995)
10
Collaboration is ...
Any activity where two (or more) partners
contribute differential resources and know-how to
agreed complementary aims in order to design and
develop a new or improved product. Dodgson
(1993) I define strategic alliances as
voluntary arrangements between firms involving
exchange, sharing, or codevelopment of products,
technologies or services. Gulati (1998)
11
Forms of collaboration
After Dussauge and Garette (1999)
12
Issues from initial case studies

• Having a conscious collaboration strategy
• The dual role of partners as both designers and
  eventual suppliers
• Designing the system architecture to support task
  partitioning
• Early definition of roles, design responsibility,
  commercial terms, cost models and IPR
• The importance of a winwin arrangement
• Communication mechanisms and value of virtual
  prototypes
• Being flexible and ready to renegotiate when
  things change, or go wrong (as they often do)
• Learning how to do it better next time
• The importance of personal contacts and long-term
  relationships in developing trust and confidence

13
What can go wrong?

• partner turns out not to have capability/
  capacity
• partner does not contribute as expected
• partners motives not aligned
• legal wrangles over contracts or IP
• insufficient flow of information,
  misunderstanding, rework
• absence of trust, Not Invented Here, them and
  us
• technical problems during system integration, who
  pays?
• no provision for support during production
• no clear maintenance policy
• exit terms not agreed in advance
• etc

14
Contract issues from cases

• Handshake, no written agreement
• cases 2, 3
• Contract prepared, but never signed
• case 9
• Agreement signed several months after project
  start
• case 1
• Written Agreement or Contract
• cases 5, 7, 10, 11, 13, 14
• absence of winwin in case 10 with connector
  supplier
• Subsequent renegotiation
• case 1 (quality)
• case 5 (bug v feature)
• case 7 (prototype functionality)
• case 11 (GUI design EMC)

15
Common Success Factors

• Choice of partner
• Commitment, stability and resource availability
• Climate of trust, respect and confidence
• Clear ground rules
• A winwin arrangement
• Open and frequent communication
• Good personal relationships
• Effective project management (realistic goals,
  milestones, resource assignment)

16
Collaboration - key process areas

• Collaboration strategy
• make-collaborate-or-buy, access to
  capability/capacity, internal competence
  development
• Structured Development Process
• stage-gate, cross-functional core teams,
  compatible development procedures/culture
• System design
• product architecture, interfaces, task
  partitioning (who owns the tools?)
• Partner search and selection
• capability, commitment, culture how thorough a
  process?
• Partnership formation
• negotiation of roles, terms, cost models, IPR
  contract v handshake
• set up management systems
• Project management
• hands on/off personal relationships virtual
  prototypes technical v commercial
• Partnership development / evolution
• changes in scope, non-conformance, exit terms
• foster long term relationships

17
Elements of collaborative maturity'

• Partner selection
• Prospective partners are carefully screened to
  ensure they have adequate capabilities and
  resources.
• Personal and cultural dimensions are also
  considered and care is taken to ensure that the
  motives and potential rewards for both parties
  are aligned.
• A risk assessment is also carried out so that
  technical and commercial risks can be identified
  and managed.
• Partnership formation and project initiation
• The roles and responsibilities of both partners
  are clearly defined and communicated. The 'lead
  partner' is identified and agreed where
  appropriate.
• A contract or agreement is in place (or under
  construction) which is satisfactory to both
  parties. IPR issues are clearly defined.
• Staff at all levels are committed to the
  partnership, with no trace of NIH.
• Partnership and project management
• There is a clear communication route between the
  partners, which is not overly dependent on key
  individuals. Communication is open and frequent,
  within a climate of trust and confidence.
• Management styles and systems are compatible.
• Both parties feel they are gaining from the
  project.
• Both parties are aware of the increased risks
  with dealing with a third party and these risks
  are managed appropriately.
• Partnership development
• It is accepted that conditions may well change,
  and that unexpected difficulties may arise. These
  are handled calmly in a non-adversarial manner.
• There a sense of investment in the relationship,
  which will pay dividends over the longer term.
  Both partners are consciously learning about the
  collaborative process with the aim of improving
  collaborative capabilities.

• Collaboration strategy
• There is a conscious identification of those
  areas of technological expertise in which
  investment tends to be concentrated. These are
  referred to as core technological competences and
  are actively developed.
• Processes exist for identifying external sources
  of expertise and these may be used to gain access
  to complementary expertise.
• Structured development process
• Product development follows a well-defined NPI
  process which is understood and respected across
  the business.
• The partner company also has a well-defined
  process, which whilst not necessarily identical,
  is nonetheless compatible.
• The NPI process allows for the possibility that
  some activities may be performed by third-parties
  and contains provision for integration and
  testing
• System design and task partitioning
• During system design, careful consideration is
  given to product architecture, creating
  well-defined modules with clear and simple
  interfaces.
• Where possible, tasks are assigned to those best
  qualified to undertake them, whether internal or
  external.
• Problems rarely occur during test and integration
  of externally developed modules, and those which
  do are quickly resolved with a minimum of fuss.

18
Collaboration Workbook

• Introduction to NPI Collaborations
• Collaboration process maturity model
• Guidelines based on life cycle
• strategy process
• partner search selection
• partnership formation
• project management
• partnership development
• Collaboration checklist
• Audit / Questionnaire
• Special issues
• Software, Industrial design

More info http//www.betterproductdesign.net/coll
aboration/workbook.htm
19
(No Transcript)
20
Process maturity / improvement

• Quality management maturity grid (Crosby 1979)
• Uncertainty, Awakening, Enlightenment, Wisdom,
  Certainty
• Quality management process maturity grid (Crosby
  1994)
• Uncertainty, Regression, Awakening,
  Enlightenment, Certainty
• Software CMM (Paulk et al 1993)
• Initial, Repeatable, Defined, Managed, Optimising
• Definition of Maturity the extent to which a
  specific process is explicitly defined, managed,
  measured, controlled, and effective
• ISO 90042000 performance maturity levels
• No formal approach, Reactive, Stable formal
  system, Continual improvement, Best-in-class

21
Maturity levels
Level 4 - Cultural Managed, enterprise wide
involvement, continuously improving performance
and seen as fundamentally important to success.
Ingrained. Proactive. Measured. Repeatable
Dont need process
Defined, consistent process
Level 3 - Formal Managed and performed well,
normally by a X- functional team. Repeatable. Not
ingrained Still room for improvement
Maturity Level
Adoption of Good Practice
Level 2 - Partial Performed, but functionally
focused and not repeatable or managed
Process, but...
Level 1 - None None. Not performed, Anarchy, Not
aware of the benefits - Individual Heroics
No process
22
Level 2
Level 1
Level 3
Level 4
(Not) Invented Here!
Collaboration Strategy Conscious choice between
internal or external sources of design and
development expertise
Occasional ad-hoc partnering
Established partners
Regular review of competences
Structured development processA clear and well
documented process to deliver new products to
market
No formal NPI process
A process exists but
Process used and understood
Continuous NPI improvement
System design Task Partitioning Design to
enable separate development and facilitate
integration of modules
Interfaces not well defined
Intuitively consider modularity
Formal configuration planning
Conscious Simultaneous Design
Word of mouth
Review of technical capability
Broad assessment of capabilities
Partner Selection Ensuring that partners have
adequate capabilities and resources
Cross fingers and hold breath
Getting Started Resources committed, with a
clear definition of roles and responsibilities
But weve already started!
Is this a good deal?
Agreement in place
All ground rules agreed and communicated
Partnership management Well defined and
effective communication paths, with regular and
open reviews of progress
I thought you were doing that
Managed but not championed
Collaboration champions
Frequent and open communication
Partnership development Building a climate of
trust and confidence, with the development of a
dependable relationship
Ill be glad when this projects over
Better the devil you know ...
Good working relationship
On-going, mutually beneficial
23
COLLABORATION STRATEGY
Conscious choice between internal or external
sources of design and development expertise
Discussion questions How effectively are core
technological competences identified and
developed? What processes exist for identifying
external sources of expertise? Ideally T
here is a conscious identification of those areas
of technological expertise in which investment
tends to be concentrated. These are referred to
as core technological competences and are
actively developed. Processes exist for
identifying external sources of expertise and
these may be used to gain access to complementary
expertise.
24
Collaboration strategy

• How effectively are core technological
  competences identified and developed?
• What processes exist for identifying external
  sources of expertise?

25
Ideally...

• There is a conscious identification of those
  areas of technological expertise in which
  investment tends to be concentrated. These are
  referred to as core technological competences and
  are actively developed.
• Processes exist for identifying external sources
  of expertise and these may be used to gain access
  to complementary expertise.

26
COLLABORATION STRATEGY
Conscious choice between internal or external
sources of design and development expertise
Discussion questions How effectively are core
technological competences identified and
developed? What processes exist for identifying
external sources of expertise? Ideally T
here is a conscious identification of those areas
of technological expertise in which investment
tends to be concentrated. These are referred to
as core technological competences and are
actively developed. Processes exist for
identifying external sources of expertise and
these may be used to gain access to complementary
expertise.
27
Maturity scorecard
28
Life-cycle analysis
29
Life-cycle analysis prompts
Phase 3 Day-to-day management

• Ideally
• There is a clear communication route between the
  partners, which is not overly dependent on key
  individuals.
• Communication is open and frequent, within a
  climate of trust and confidence.
• Management styles and systems are compatible.
• Both parties feel they are gaining from the
  project.
• Both parties are aware of the increased risks
  with dealing with a third party and these risks
  are managed appropriately.

• Typical problems
• Managers responsible for running the project were
  not involved in the setting up of the
  collaboration, so some familiarisation or
  renegotiation is needed.
• Failure to set sharp milestones makes progress
  checking difficult
• Over-dependence on one or two key individuals for
  either technical or development or information
  exchange. Becomes apparent if someone is on
  holiday or leaves the company.
• Incompatible systems - email systems, document
  formats, software tools, CAD formats, metric v
  imperial units, spoken language, time zones,
  accounting conventions
• No contingency to deal with unexpected events
  (which always crop up)
• The partner has subcontracted some of the work,
  so the design chain is more complex and less
  responsive to requests for design changes

30
Life-cycle scorecard - example
31
(No Transcript)
32
Discussion

• Collaborative process maturity
• what is it and how to get it?
• maturity grids codify good (and not-so-good)
  practice
• Audit v Actions for improvement

33
Contract and Trust

• Contract
• businessmen often fail to plan exchange
  relationships completely, and seldom use legal
  sanctions to adjust these relationships
  (Macauley 1963)
• "Prudent managers realise that there are
  limitations to what can be written into a
  contract to ensure joint venture success.
  Alliances fail because operating managers do not
  make them work, not because contracts are poorly
  written. (Harrigan 1986)
• .. analysis suggests that contracts and
  agreements should avoid detailed specifications
  of the procedures to be followed during
  implementation. Such stipulations create problems
  by reducing the flexibility required in
  inherently uncertain RD collaborations.(Hakanson
  1993)
• Trust
• contractual, competence and goodwill trust (Sako
  1992)

34
Conclusions

• Collaboration framework derived from literature
  and cases
• Draft Workbook containing several tools
• collaboration maturity model
• lifecycle analysis
• checklist
• Existence of contract is not in itself a sign of
  maturity
• what matters is attitude to contract
• Contract is basis for relationship
• not an exhaustive list of clauses for all
  eventualities
• some specifics such as IPR ownership
• Much is taken on trust