Collaboration

Few firms have all the skills and resources to develop technologically complex products themselves. Increasingly, firms choose to concentrate on core technologies and opt to collaborate with others to gain access to complementary skills and resources. Others have experienced downsizing and have little choice but to outsource a number of operations. This may sometimes include design and development activities where the design responsibility for a part or subsystems either shared or wholly delegated to a third party.

Product development is difficult enough when done purely in-house. Collaboration brings additional challenges!

A typical co-development project goes through a number of main phases: Preparation, Formation, Management, Evolution and Conclusion. In some cases, the relationship may end after the completion of the initial project. In other cases, further collaborative projects may ensue, with the partner companies entering a continuing relationship which may span several projects. Even so, these on-going relationships may in time dissolve, with the cycle restarting once more.

Phase	Key activities	Typical problems
Preparation	Product development strategy Product architecture design Deciding what to do in-house Identifying a number of candidate partners Performing a structured selection process	The NPI process is not well established and does not deal specifically with external partnerships. Core skills and competences are not reviewed systematically, and not linked to training and recruitment policy. External expertise is accessed sporadically Either partner has a 'hidden agenda' (e.g. potential acquisition, or technology transfer)
Formation	Agreeing ground rules Agreeing commercial terms and win:win scenarios Assigning roles and responsibilities Assigning IPR Defining communication and coordination mechanisms	Insufficient time or resources allocated to partner search and selection, so partner may not actually have all capabilities required An over-formal or rigid selection process may antagonise prospective partners or introduce delays Over-estimating the partner's capability Supplier may use specialist resources to win the business which are not available during the project Poor system design and task partitioning with too many interdependencies leading to problems downstream Difference of expectation over the need for a written contract Adversarial approach due to lack of trust, failure to generate a win:win solution. Internal politics, lack of buy-in, NIH, 'them and us', leading to lack of commitment to collaborative project.
Management	Communicating regularly andy on progress Identifying and managing risks Committing adequate resources	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 Incompatible NPI process or working practices, cultural differences, formal v informal processes 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
Evolution	Adopting a flexible approach to deal with new opportunities or unexpected problems	It emerges that the capabilities of the partner are not as expected. Some work may need to be taken back in-house or re-sourced. An escalation procedure has not been defined in advance, so a framework for resolving problems has to be negotiated from scratch In a medium or large company, the decision loops may be longer (and slower) due to the involvement of multiple layers of management than in a smaller company where the same people are involved.
Conclusion	Establishing plans for long-term production and support Dissolving the partnership on good terms as and when appropriate Learning on how to do it better next time Continuing with a new project	Exit terms weren't negotiated up-front, so there are several loose ends to tidy up, with possible disagreement over final payment Uncertainty over the ownership of joint assets, materials or inventory Support and maintenance agreements not in place - who fixes software bugs, who pays? With a development partner, will there be support available when the product eventually goes into pre-production?

Few medium-sized companies have formal processes for managing collaborative projects, although the NPD process itself may be defined for ISO9000 purposes. A process maturity approach may help to raise awareness of collaboration issues and pinpoint areas for improved practice. A collaboration maturity grid summary is shown below:

A workbook entitled 'Managing product development collaborations' is available to provide support in starting, managing and concluding collaborative development projects. The workbook can be ordered from the Institute for Manufacturing.