Product Development Collaborations - Pitfalls and Opportunities

1
Product Development Collaborations - Pitfalls
and Opportunities
2
Why collaborate?

• In a knowledge driven economy, partnership is
  essential to competition. To exploit our
  capabilities in people and technologies,
  businesses have to collaborate across sectors,
  throughout regions and with education.
• Few companies have all the skills needed to
  develop technologically complex products and to
  market their products and services effectively.
• Businesses are increasingly involving suppliers
  and allies in product design, development and
  delivery.
• The most dynamic regional economies, such as
  Silicon Valley, have businesses which rely on
  each other to solve shared problems while still
  competing intensely.
• Competitiveness White Paper, Our Competitive
  Future Building the Knowledge Driven Economy,
  (DTI, 1998)

3
Collaboration partnersvertical and horizontal
Customers
Producers of complementary products
Firm
Competitors
Universities RD organisations Design Consultants
Suppliers
After Millson, Raj Wilemon (1996)
4
Evolution of collaboration issues

• How to manage outsourcing
• early supplier involvement (ESI)
• How to manage non co-located Design Development
• between separate DD centres of same firm
• between collaboration partners in separate firms
• . . . Towards the virtual organisation?
• virtual co-location

5
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)
6
NPI Process in vertically integrated firm
Fuzzy front end Concept development Specification
Design development
Technology development
Production
Sales distribution
Strategy, Ideas Knowledge
7
Collaboration and NPI Process
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
Industrial Design and Consultancy
the virtual corporation
After Wheelwright Clark (1992), Rothwell
(1992, 1994), Biemans (1995)
8
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.
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)
9
What can go wrong?
10
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

11
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)

12
Collaboration Workbook
13
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

14
Collaboration - a process approach

• Collaboration strategy
• make-collaborate-or-buy, competence development
• Structured Development Process
• stage-gate, cross-functional core teams,
  development procedures
• System design
• product architecture, interfaces, task
  partitioning
• Partner search and selection
• capability, commitment, culture
• Partnership formation
• negotiation of roles, terms, cost models, IPR
• set up management systems
• Project management
• day to day issues, communication
• Partnership development / evolution
• changes in scope, non-conformance, exit terms
• foster long term relationships

15
Partnership Themes (process focus)
Collaboration strategy
Structured NPI Process
System design and Task partitioning
NPI Collaboration
Partner search selection
Getting started
Management and evolution of partnership
Lifecycle of partnership (project focus)
Preparation
Search selection
Partnership formation
Management
Evolution
Conclusion
(do you have one?)
16
Assessment process
Preparation Preliminary assessment
Stage 1
Internal Audit Buyer side
Internal Audit Supplier side
Stage 2
Joint Workshop Share results, walk-through process
Stage 3
Project Review After significant project milestone
Stage 4
17
Collaboration issues
18
Forms of collaboration
19
Design responsibility
Buyer / Customer / Manufacturer

• The supplier provides input into a products
  design by sharing information on equipment and
  capabilities.
• The supplier provides feedback on design
  including suggestions for cost and quality
  improvements
• The supplier participates significantly in the
  design of a part or component by executing
  detailed drawings based on a clients rough
  sketches.
• The supplier takes full responsibility from
  concept to manufacture for the design of an
  entire part or subassembly.
• The supplier takes full responsibility from
  concept to manufacture for the design of a system
  or subassembly incorporating one or more parts
  which the supplier also designed

Buyer / Customer / Manufacturer has primary
design authority
Shared design
Supplier responsible for majority of design of
module
Supplier / Partner
After Bidault et al (1998)
20
Domains of experience
Customers expertise - wide and system oriented
Components used in the system
Suppliers expertise - deep and component specific
After Schrader and Göpfert (1997)
21
Task partitioning
Task partitioning according to task
interdependencies
Task partitioning according to domain of expertise
A
1
1
2
2
3
3
6
6
4
5
4
5
B
B
A
7
7
Task belonging to As domain of expertise
Task belonging to Bs domain of expertise
After Schrader and Göpfert (1997)
22
Design example Spectrophotometer

• 3 person in-house team
• 10 person external team from 5 organisations
• 15 month development timescale
• Highly paralleled design process

23
Design process 1 Sequence
Outline brief
Optics design
Contextual engineering
User manual
Case design
Software design
Virtual product
Optics layout
Hardware design
Opto-electronics design
Power design
done in-house
outsourced
joint activity
24
Design process 2 Specifications

• Boundary design
• Minimised interfaces choose the minimum crossing
  point
• Specify what rather than how
• Tightly specify the interactions with other
  modules e.g size, I/O, handshaking, heat etc
• Tightly specify global requirements e.g cost,
  based on value engineering
• Define testing and acceptance criteria
• Ensure there is adequate post development support

25
Trust v Contract
Trust
No Trust
Fully committed
Arms-length, Adversarial
Contract
No deal?
Open Partnership
No Contract
Balancing trust and contract
26
Trust v Contract
Trust
No Trust
Happily married
Divorce pending?
Contract
One night stand?
Co-habiting
No Contract
27
Workbook tool 1Collaboration life-cycle analysis
28
Collaboration life cycle
0 Ground state
1 Preparation
2 Formation
3 Management
4 Evolution
5 Conclusion
6 New Ground state
Time
29
Key issues through the Life-cycle
Preparation
Formation
Management
Conclusion
Evolution
30
Life-cycle exercise

• Life cycle analysis, based on skeleton
  mini-case
• (youd normally do this on your own live project)
• You play the part of a manager in Company A which
  is contemplating a collaborative project. The MD
  is keen to get started...
• Your team meets to discuss potential issues ahead
  of the next meeting with each prospective
  partner, e.g.
• What will be the nature of the collaboration
  agreement?
• What will be the nature of the collaboration
  process?
• What might be the possible pitfalls and
  opportunities?
• What issues will you want on the agenda?

31
Instructions

• Get into 4 groups Get some coffee
• Read the case briefing - dont be too literal! (5
  mins)
• Nominate a scribe / scorer
• Taking each phase in turn, review what might
  happen in the project. Which issues might be
  problematical? (25 mins)
• Summarise your findings on the scorecard.
• Group feedback (5 mins per group)
• Be particularly on the lookout for problems which
  may only become apparent downstream, perhaps
  during pre-production or after product launch

32
Life-cycle scorecard
33
Life-cycle analysis - next steps

• Collate the issues on the summary scorecard
• Describe the effect, impact and severity of each,
  e.g.
• What would be the immediate impact on the
  project?
• How long would it take to replace the outsourced
  module?
• What would it cost?
• How likely are the identified 'failure modes'?
• Identify the actions to be taken to control or
  eliminate the risk
• Assign responsibility for managing the risk
• Discuss the key factors with your current or
  prospective partner so that each understands the
  others perspective and common areas for concern
  can be targeted.

34
(No Transcript)
35
Life-cycle scorecard - example
36
(No Transcript)
37
Workbook tool 2Collaboration process maturity
38
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
• ISO 90042000 performance maturity levels
• No formal approach, reactive, stable formal
  system, continual improvement, best-in-class

39
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
40
(No Transcript)
41
Collaboration strategy

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

42
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.

43
(No Transcript)
44
Maturity scorecard
45
Action planning
46
(No Transcript)
47
Conclusions if the capacity to collaborate
is not already a core competence in your
organisation, you had better get busy making it
so.

• Explore the opportunities, beware the pitfalls!
• Consider the maturity of your collaboration
  process
• Review past and future projects
• Review your collaboration strategy / process
• Refer to the workbook
• We welcome your feedback
• this workshop
• the workbook

48
Structured development process

• How widely understood is the current NPI process
  across the business and does everyone understand
  their role?
• How successful is the process in providing
  appropriate levels of management control, without
  constraining creativity?
• How effectively are metrics used (if at all) to
  measure success of individual projects or success
  across projects?
• Are collaboration issues explicitly reflected in
  your NPI process?
• (Does your collaborator have a compatible
  process?)

49
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

50
(No Transcript)
51
System design Task partitioning

• How effective is the system design process in
  creating well-defined modules with clear and
  simple interfaces?
• How are tasks assigned to those best qualified to
  undertake them?
• Do problems occur during test and integration of
  externally developed modules? Why?

52
System design 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.

53
(No Transcript)
54
Partner selection

• How do you determine whether prospective partners
  have adequate capabilities and resources?
• How do you determine and manage risk associated
  with depending on a third party?

55
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.

56
(No Transcript)
57
Getting started (partnership formation)

• How do you ensure that the ground rules are in
  place and that adequate resources are allocated?
• How do you identify and negotiate the issues to
  be included in the agreement or contact?

58
Getting started (partnership formation)

• 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.

59
(No Transcript)
60
Partnership management

• Is there a clear communication rote between the
  partners, not overly dependent on key
  individuals?
• Are the management styles and systems compatible?
• Are staff at all levels committed to the
  partnership, with no trace of NIH?
• How strong is communication - both within a
  project team and outside of the project team?

61
Partnership 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.

62
(No Transcript)
63
Partnership development

• To what extent is there a sense of investment in
  the relationship, which will pay off over the
  longer term?
• To what extent are your relationships adversarial
  as opposed to winwin?

64
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.
• The exit conditions for the current collaboration
  are clearly defined and understood, but a
  successful outcome is expected and it is likely
  that further collaborative projects will be
  undertaken in the future.

65
(No Transcript)
66
Conclusions if the capacity to collaborate
is not already a core competence in your
organisation, you had better get busy making it
so.

• Explore the opportunities, beware the pitfalls!
• Consider the maturity of your collaboration
  process
• Review past and future projects
• Review your collaboration strategy / process
• Refer to the workbook
• We welcome your feedback
• this workshop
• the workbook