David C. Robson, Principal, Robson Advisors12.05.17
I recently attended a closing on a house. The amount of detail that the lawyers went into in preparing the documents, including calculations of taxes owed and title insurance, to the final walkthrough signoffs was, well, dizzying. Although it all seemed overdone for what ended up being a simple, uncontested, friendly exchange, each of those documents had a critical purpose in protecting both parties from mistakes and misunderstandings—whether intentional or innocent.
Negotiating with service providers to help a medical device company move through the design-to-production process should be afforded the same attention to detail and documented rigor as a house closing. On occasion, it may seem similarly overdone and unnecessarily time consuming but it can save the buyer from a lot of frustration when things get sticky.
Following are ten points that should be considered when generating a client's request for quotation. Further, these should be clearly spelled out within the service provider's proposal and the eventual work agreement. By insisting on these details during the quoting and negotiating process, a client company may find that some otherwise good-looking firms fall out of contention while others rise to the top.
Note: If the client's internal team isn’t well versed in some of these areas, consider bringing a third party into the negotiating process to act as the client's representative or advocate. By reducing the risk of errors and miscommunications, the client will save time, money, and a lot of heartache.
1. Start with a clear statement of work.
It is surprising how often a client company starts shopping for a development partner without having a clearly written statement of work (SOW) or request for quotation (RFQ). After getting a non-disclosure agreement in place, the client should send along a detailed SOW or RFQ to potential service providers outlining what needs to be accomplished and what should be quoted. There should be a project summary, preferably with pictures and diagrams of the current state of the product design. If it’s a rough feasibility prototype, show that. If it’s a basic diagram and some circuitry, show that. Whatever is provided will give the receiving company something to gage how much work needs to be performed. Likewise, the client company should describe the portions of the design that are complete and what portions still require work. If the regulatory path or the manufacturing method is already known or the annual manufacturing quantities are already forecast, those details should be included.
In addition to providing background information, the client company needs to describe what it is seeking to accomplish. What are the goals that the quoting company should keep in mind as it establishes a proposal? Are there key dates to keep in mind? Are the project goals linked to particular investment milestones? For instance, if funds are still being raised, the goals may be more related to that effort rather than product development, which can make a significant difference in how to proceed with a development partner.
Most importantly, the SOW/RFQ provides a written and (hopefully) clear document for the client company to share with all of the organizations being considered. It allows key areas of importance to be listed and provides a reference point if confusion or disagreements emerge later in the project.
2. Insist on a detailed proposal, plan, and budget.
In the SOW/RFQ, the client should require that the development firm’s proposal include a detailed outline of the intended processes and deliverables, as well as details on how budget and schedule forecasts are generated. If there are particular deliverables due within specific phases, ensure the development firm's plan reflects those milestones. This will help the client company better understand various firms' plans and probe for weak spots. The ultimate goal is to ensure all prospective vendors have adequately understood the work scope and been able to anticipate the steps needed as well as the resources it will take to get through the program. It will also be a glimpse into how the vendor will handle the project from a client management perspective. The more depth of thought and attention to detail that the vendor invests in the proposal, the better.
3. Insist on knowing the nitty gritty of the budget.
Just as there is no such thing as a free lunch, there is no such thing as an unlimited fixed price agreement. There are always caveats and clauses intended to protect the service provider. So, even if the proposal is offered as a fixed fee arrangement, it is essential to know the underlying details.
In addition to the global or macro level details of phase costs and durations (e.g., $350k x 4 months), the client company should insist on knowing the billing rates for all of the resources that will be used in the program. Further, the client should also know how the various resources will be engaged throughout the project and the budget allowances for each. This is not to say the resource plan is locked in place. Also, the client should know what allowances have been made for expenses associated with prototypes and travel and how those expenses are charged.
It is almost inevitable that budget and resource changes will occur. Things will emerge that neither party had expected or planned. By having these details out in the open, however, the client can get a sense of whether the development partner seems to have adequately forecasted. Also, by having these details from all of the firms under consideration, the client company can look for large discrepancies between them, which may help identify problems or misunderstandings.
4. Insist on intellectual property ownership.
This is a fairly obvious point but needs to be overtly pointed out: If the client company is paying a development firm or any service provider to work on its behalf, the client should ensure there is clear language that it owns all resulting intellectual property (IP). For instance, the client should not accept any equivocating language that the development firm retains rights to use resulting IP in non-competitive spaces. Further, except perhaps for the case of a client company egregiously failing to pay its bills, it should own the IP rights at all times; not at the end of the project or after the final invoice has been paid.
Of course, if the development firm or service provider has pre-existing IP being used within the client's solution (and the client has approved of in advance), there should be clear language outlining the client's rights and what, if any, obligations there are for licensing payments or royalties.
For some firms, this topic is a very matter-of-fact bit of language in their business terms, which will be acceptable to the client organization. The terms and conditions need to be carefully reviewed and the legal implications clearly understood.
5. Insist on detailed invoices and budget summaries every month.
Traditionally, invoices are sent to clients once per month. These can often simply show a cost for services and a cost for expenses. But, as the customer, the client should insist on seeing much more. The client should request a list of the individuals who worked on the project and the hours and hourly rates billed by them. The client should also request a listing of all expenses incurred. Further, the client should request a summary of how these charges compare against the projected costs for the project or phase.
For some organizations, this type of information will be readily available at the push of a button or by the running of a report. For others, there may be resistance and excuse making of it “taking too long to compile” or “distracting from the actual work of the project.” If it’s a small and relatively short work scope then perhaps the client can forego this type of information request. In general, however, this is a good way to track the progress of the vendor and keep it focused on how it is spending money. In fact, the client should consider requesting this type of information during the business negotiations before awarding the work so that both parties know one another’s stance on this type of request.
6. No team changes without notice.
Part of a client's decision in selecting a service provider is getting to know and becoming comfortable with their team. It is perfectly reasonable that the client should insist on the service provider's team members not being changed without advanced notice. More specifically, the client should not have to pay for the “getting up to speed” time it might take in the event a key person must be replaced on the team. While this orientation time may be hard to quantify, it certainly isn’t zero hours and the client company shouldn’t be charged for changes not related to normal, planned resource adjustments.
7. Know the development firm's billing policy for travel.
Billing practices for travel may seem like a detail that doesn’t need its own section but it can make a big difference depending upon the service provider’s location and where they need to go. The key is for the client to know the vendor's policy in detail so that it knows how to arrange and approve vendor trips, meetings, field research, etc. There are not necessarily right or wrong answers to the following probing questions, but they may help focus the discussion.
8. Get biographies on all team members.
It can be very helpful and reassuring to see the backgrounds and experience of the proposed team members. Of course, it can be concerning as well. Seeing a biography for each core team member can help the client assess whether it is getting the right combination of experiences and disciplines. It should be a simple matter for a prospective service provider to provide this information. For truly critical roles, the client should consider double checking everything via LinkedIn or similar information source. If the client views something it doesn’t like or is unsure about, it should ask for more information, request a preliminary interview, or perhaps demand a personnel change.
9. Put a conflict resolution plan in place.
This is something that’s been nagging at me for years and probably warrants its own article. There should be a clear, two-way path for a client and service provider to follow when they become concerned or unhappy over something. Usually the development firm has a day-to-day project manager who can handle the “normal” issues that may arise. When larger concerns present themselves (e.g., budget overruns, poor performance, inappropriate behavior, or major work scope disconnections), there should be someone the client knows who has the responsibility and authority to investigate the matter and make adjustments as required.
10. Maintain open and constant access channels.
There are horror stories of client companies that had trouble with a service provider and then felt as if they were being held hostage because they couldn’t get to the work already paid for. This has resulted in extreme client frustration and distrust, which is virtually impossible to repair. Of course, not every problem or disagreement has a clear “good guy” and “bad guy,” but if the client company has already paid for the work, they should always have access to it.
With the advent of cloud storage and VPN access, there is no reason a client company should have to request access to project work. While work in progress may not be immediately available, the vast majority of memos, reports, drawings, CAD files, presentations, budget summaries, and other related materials should be readily accessible and reasonably well organized.
Conclusion
There are undoubtedly dozens of other details that should be considered when negotiating a product development outsourcing agreement. Of course, the size of the project and the amount of know-how the client company has will influence how much of this list is necessary. A number of these items, however, are often overlooked and yet, can have a significant impact on the selection process and overall client-vendor relationship.
In seeing how a potential development partner responds to these requests, the client company will better understand how transparent and customer centric the vendor is prepared to be. Of course, the more transparent and customer centric they are, the better experience the client is likely to have.
David C. Robson, a principal at Robson Advisors, has spent 30 years concentrating on the development of medical devices. The last 17 of those years have been spent working for a full-service product development firm where he interacted with both large and small medical device companies and reviewed statements of work and requests for quotation, wrote proposals, and negotiated hundreds of work agreements. Robson and his partners now offer product development guidance and advocacy to early-stage medical device clients.
Negotiating with service providers to help a medical device company move through the design-to-production process should be afforded the same attention to detail and documented rigor as a house closing. On occasion, it may seem similarly overdone and unnecessarily time consuming but it can save the buyer from a lot of frustration when things get sticky.
Following are ten points that should be considered when generating a client's request for quotation. Further, these should be clearly spelled out within the service provider's proposal and the eventual work agreement. By insisting on these details during the quoting and negotiating process, a client company may find that some otherwise good-looking firms fall out of contention while others rise to the top.
Note: If the client's internal team isn’t well versed in some of these areas, consider bringing a third party into the negotiating process to act as the client's representative or advocate. By reducing the risk of errors and miscommunications, the client will save time, money, and a lot of heartache.
1. Start with a clear statement of work.
It is surprising how often a client company starts shopping for a development partner without having a clearly written statement of work (SOW) or request for quotation (RFQ). After getting a non-disclosure agreement in place, the client should send along a detailed SOW or RFQ to potential service providers outlining what needs to be accomplished and what should be quoted. There should be a project summary, preferably with pictures and diagrams of the current state of the product design. If it’s a rough feasibility prototype, show that. If it’s a basic diagram and some circuitry, show that. Whatever is provided will give the receiving company something to gage how much work needs to be performed. Likewise, the client company should describe the portions of the design that are complete and what portions still require work. If the regulatory path or the manufacturing method is already known or the annual manufacturing quantities are already forecast, those details should be included.
In addition to providing background information, the client company needs to describe what it is seeking to accomplish. What are the goals that the quoting company should keep in mind as it establishes a proposal? Are there key dates to keep in mind? Are the project goals linked to particular investment milestones? For instance, if funds are still being raised, the goals may be more related to that effort rather than product development, which can make a significant difference in how to proceed with a development partner.
Most importantly, the SOW/RFQ provides a written and (hopefully) clear document for the client company to share with all of the organizations being considered. It allows key areas of importance to be listed and provides a reference point if confusion or disagreements emerge later in the project.
2. Insist on a detailed proposal, plan, and budget.
In the SOW/RFQ, the client should require that the development firm’s proposal include a detailed outline of the intended processes and deliverables, as well as details on how budget and schedule forecasts are generated. If there are particular deliverables due within specific phases, ensure the development firm's plan reflects those milestones. This will help the client company better understand various firms' plans and probe for weak spots. The ultimate goal is to ensure all prospective vendors have adequately understood the work scope and been able to anticipate the steps needed as well as the resources it will take to get through the program. It will also be a glimpse into how the vendor will handle the project from a client management perspective. The more depth of thought and attention to detail that the vendor invests in the proposal, the better.
3. Insist on knowing the nitty gritty of the budget.
Just as there is no such thing as a free lunch, there is no such thing as an unlimited fixed price agreement. There are always caveats and clauses intended to protect the service provider. So, even if the proposal is offered as a fixed fee arrangement, it is essential to know the underlying details.
In addition to the global or macro level details of phase costs and durations (e.g., $350k x 4 months), the client company should insist on knowing the billing rates for all of the resources that will be used in the program. Further, the client should also know how the various resources will be engaged throughout the project and the budget allowances for each. This is not to say the resource plan is locked in place. Also, the client should know what allowances have been made for expenses associated with prototypes and travel and how those expenses are charged.
It is almost inevitable that budget and resource changes will occur. Things will emerge that neither party had expected or planned. By having these details out in the open, however, the client can get a sense of whether the development partner seems to have adequately forecasted. Also, by having these details from all of the firms under consideration, the client company can look for large discrepancies between them, which may help identify problems or misunderstandings.
4. Insist on intellectual property ownership.
This is a fairly obvious point but needs to be overtly pointed out: If the client company is paying a development firm or any service provider to work on its behalf, the client should ensure there is clear language that it owns all resulting intellectual property (IP). For instance, the client should not accept any equivocating language that the development firm retains rights to use resulting IP in non-competitive spaces. Further, except perhaps for the case of a client company egregiously failing to pay its bills, it should own the IP rights at all times; not at the end of the project or after the final invoice has been paid.
Of course, if the development firm or service provider has pre-existing IP being used within the client's solution (and the client has approved of in advance), there should be clear language outlining the client's rights and what, if any, obligations there are for licensing payments or royalties.
For some firms, this topic is a very matter-of-fact bit of language in their business terms, which will be acceptable to the client organization. The terms and conditions need to be carefully reviewed and the legal implications clearly understood.
5. Insist on detailed invoices and budget summaries every month.
Traditionally, invoices are sent to clients once per month. These can often simply show a cost for services and a cost for expenses. But, as the customer, the client should insist on seeing much more. The client should request a list of the individuals who worked on the project and the hours and hourly rates billed by them. The client should also request a listing of all expenses incurred. Further, the client should request a summary of how these charges compare against the projected costs for the project or phase.
For some organizations, this type of information will be readily available at the push of a button or by the running of a report. For others, there may be resistance and excuse making of it “taking too long to compile” or “distracting from the actual work of the project.” If it’s a small and relatively short work scope then perhaps the client can forego this type of information request. In general, however, this is a good way to track the progress of the vendor and keep it focused on how it is spending money. In fact, the client should consider requesting this type of information during the business negotiations before awarding the work so that both parties know one another’s stance on this type of request.
6. No team changes without notice.
Part of a client's decision in selecting a service provider is getting to know and becoming comfortable with their team. It is perfectly reasonable that the client should insist on the service provider's team members not being changed without advanced notice. More specifically, the client should not have to pay for the “getting up to speed” time it might take in the event a key person must be replaced on the team. While this orientation time may be hard to quantify, it certainly isn’t zero hours and the client company shouldn’t be charged for changes not related to normal, planned resource adjustments.
7. Know the development firm's billing policy for travel.
Billing practices for travel may seem like a detail that doesn’t need its own section but it can make a big difference depending upon the service provider’s location and where they need to go. The key is for the client to know the vendor's policy in detail so that it knows how to arrange and approve vendor trips, meetings, field research, etc. There are not necessarily right or wrong answers to the following probing questions, but they may help focus the discussion.
- Is the development firm billing for “portal-to-portal” travel time or just actual meeting time?
- Is the development firm billing for a full day even if the meeting is only a couple hours long?
- Is the development firm billing for a coach class air ticket or something more expensive?
- Is the development firm billing for all of their meals and expenses and, if so, is there a per diem limit?
8. Get biographies on all team members.
It can be very helpful and reassuring to see the backgrounds and experience of the proposed team members. Of course, it can be concerning as well. Seeing a biography for each core team member can help the client assess whether it is getting the right combination of experiences and disciplines. It should be a simple matter for a prospective service provider to provide this information. For truly critical roles, the client should consider double checking everything via LinkedIn or similar information source. If the client views something it doesn’t like or is unsure about, it should ask for more information, request a preliminary interview, or perhaps demand a personnel change.
9. Put a conflict resolution plan in place.
This is something that’s been nagging at me for years and probably warrants its own article. There should be a clear, two-way path for a client and service provider to follow when they become concerned or unhappy over something. Usually the development firm has a day-to-day project manager who can handle the “normal” issues that may arise. When larger concerns present themselves (e.g., budget overruns, poor performance, inappropriate behavior, or major work scope disconnections), there should be someone the client knows who has the responsibility and authority to investigate the matter and make adjustments as required.
10. Maintain open and constant access channels.
There are horror stories of client companies that had trouble with a service provider and then felt as if they were being held hostage because they couldn’t get to the work already paid for. This has resulted in extreme client frustration and distrust, which is virtually impossible to repair. Of course, not every problem or disagreement has a clear “good guy” and “bad guy,” but if the client company has already paid for the work, they should always have access to it.
With the advent of cloud storage and VPN access, there is no reason a client company should have to request access to project work. While work in progress may not be immediately available, the vast majority of memos, reports, drawings, CAD files, presentations, budget summaries, and other related materials should be readily accessible and reasonably well organized.
Conclusion
There are undoubtedly dozens of other details that should be considered when negotiating a product development outsourcing agreement. Of course, the size of the project and the amount of know-how the client company has will influence how much of this list is necessary. A number of these items, however, are often overlooked and yet, can have a significant impact on the selection process and overall client-vendor relationship.
In seeing how a potential development partner responds to these requests, the client company will better understand how transparent and customer centric the vendor is prepared to be. Of course, the more transparent and customer centric they are, the better experience the client is likely to have.
David C. Robson, a principal at Robson Advisors, has spent 30 years concentrating on the development of medical devices. The last 17 of those years have been spent working for a full-service product development firm where he interacted with both large and small medical device companies and reviewed statements of work and requests for quotation, wrote proposals, and negotiated hundreds of work agreements. Robson and his partners now offer product development guidance and advocacy to early-stage medical device clients.
