Partner Agreement Thoughts, Case References and Summary
In the first three parts of this series of blogs, we introduced tools and best practices for finding, qualifying and managing a product development partner relationship in a robust manner, independent of the type of project or product under development. In Part 4, we included the principles of the Agile Manifesto to demonstrate the benefit of those principles for developing either software or hardware products. The reason for this order is that Agile product development requires a much tighter collaboration than traditional “waterfall” methodologies, so the organization should first develop excellence in the basics of partner management before attempting agile methods.
Regarding partnership agreements, agile product development as described above calls for much more trust-based contracting than just a fixed fee for a fixed deliverable. Time and materials contracts can work, but many prime companies fear that they represent a “blank check” for the partner. This fear is understandable, but usually not well-founded because the partner would like to be a long-term contractor and so is motivated not to overcharge. Such contracts often include incentives for early delivery and corresponding penalties for lateness or other problems.
We have found that getting the most from a partner is done using some kind or risk-reward sharing contract. The partner is paid a base amount for time and materials (perhaps just covering their costs) and then rewarded with some percentage of the revenues or profits from the product once it is on the market. In this kind of arrangement, the partner is motivated to contribute his best people and highest standards of innovation to help the product succeed and get to market on time.
In summary, to be truly competent in new product development, almost all companies today must have strong core competencies in partner management. Many companies do well at product lifecycle management, and yet very few put much effort into managing the lifecycles of their partner relationships to get the maximum benefit. Asking a partner to “go away and develop a subcomponent” of your product often extends the development schedule, causes overspending and can lead to animosity due to changing requirements and expectations. Furthermore it takes little advantage of your partner’s ability to contribute to the innovation or value proposition of your offering. And in too many cases, a partner is used for just one project and your team starts over with a new partner on the next project – thereby wasting the big investment in the first three phases of the Partner Relationship Lifecycle.
We have presented a case for managing partners with excellence, plus we have presented some simple graphical tools and best practices to help with various phases of the partner relationship. Excellence in managing partners is not difficult, but it takes training, practice and striving for continuous improvement.
Managing partners to collaborate in Agile methodology development projects is more difficult, but if the basics above are first mastered and the principles of the Agile Manifesto are followed as we have described, these collaborations can be very successful; yielding valuable products in a short time that meet the customer needs precisely.
Here are some case studies of companies who have uses Agile methods for hardware development:
How We Learned to Built [sic] Hardware, the Agile way
By Francisco Javier Zorzano Mier, Feb. 24, 2014
Interview: what hardware developers can learn from software developers
By Jon Stevenson, October 28, 2013
PhD Thesis from Sweden: The Challenges of Becoming Agile
By Nis Oveson, June 2012
Dr. Oveson presents 7 case studies (anonymously)
Your comments are welcome! Particularly if you have any experience using Agile methods in a hardware or system product development.