In this series of blogs, Mark Danna, Owens Design’ VP for new business development, will highlight common mistakes that can cause an outsourced partnership to fail and detail a methodology for approaching an outsourcing agreement that can minimize the risk and costs involved and help ensure a successful partnership.
The prior 3 posts in this series covered when to outsource, how to choose an outsourcing partner, and qualifying your partner.
October 18, 2011 — So, you’ve decided you’re going to outsource a particular project because the expertise involved is outside the core competency of your company, and you believe teaming with an outsourcing partner can speed the development time and reduce the costs of your new product. You’ve done a careful job vetting potential partners, and picked one that has the right skill set and a business model complementary to your own, as well as a project development approach that meets your particular needs. Now, how do you make sure that what you get at the end of the project is what you want? As always, the devil is in the details — here, the project specification.
One of the first things to understand is that developing an effective project spec requires more than just setting down a series of target data points on a sheet of paper and passing them off to your outsourcing partner. Depending on the nature and scope of the project, your project specification may need to be a living document, capable of reflecting any changes that occur during development. It’s highly likely that altering a particular specification during the design process will impact other project specifications.
There are also numerous key areas that need to be included to avoid delays, misunderstandings, and unexpected development costs. These include at a minimum: functional/technical concerns, product documentation, ownership and responsibility for specific project aspects, an assessment of any technical risks, along with a risk mitigation plan, tool validation and test and marketing input. Depending on the specific project, there may be other areas that need to be included as well.
Functional and technical concerns include such issues as tool throughput, its desired footprint (size), process parameters, serviceability and maintenance requirements as well as reliability. The type of factory interface also raises a concern, as do environmental requirements. The global regions, to which the tool is expected to be deployed, for example, can have a significant bearing on how “green” you have to make your product.
The types and level of documentation should also be established in the project spec. It’s a lot easier to develop the required documentation over the course of the project than to try to create it at the end. At a minimum, project documentation should include relevant regulatory requirements, safety requirements, a system block diagram and system operational flow.
One of the surest ways to guarantee that a project will run over cost and miss the desired time-to-market window is to have confusion over ownership of project responsibilities. A well-written project spec, therefore, clearly delineates those responsibilities. It also clearly establishes all the interfaces that will be necessary between you and your outsourcing partner, as well as highlighting any project issues that can only be resolved as the project develops. In such cases, you need to establish a timeframe for when those answers are required.
It’s also important to identify upfront any potential technical risks and have clear plans for dealing with them. This helps minimize unpleasant surprises and subsequent finger pointing that can sour the partnership and waste valuable development time. In just the same way, and for many of the same reasons, it’s critical to establish tool validation criteria and the tests that will be required to ensure it meets specification requirements. Some of the validation criteria, for example, can have a direct bearing on how the tool is designed.
Finally, it’s critical to get input from marketing at the time the project specification is being written. You want to have a clear idea of how much the tool is going to cost and how you want it to look before you start building it. Your customers are not going to be terribly pleased if you’ve promised them the equivalent of a low-cost-of ownership Volkswagen and you try and deliver a high-end Ferrari, or vice versa.
Most of us have heard the old epigram about proper preparation preventing poor performance. When it comes to outsourcing a development project, proper preparation involves paying attention to the details up front.
Catch up on the How to outsource series:
When to outsource: Ask the right questions and avoid pitfalls
Picking the right outsourcing partner
How to qualify your outsource selection before you write the check