If you’re the person in your organization responsible for buying sophisticated software-controlled products – for example, corporate phone systems, advanced medical devices, call center technology – you routinely face a host of complex considerations. In most such cases (which I refer to as “technology procurement transactions”), the products are not purchased off the shelf; rather, they tend to be customized to address the buyer’s peculiar needs.
But no matter what unique customization features any particular acquisition entails, it is important to recognize that certain issues and concerns tend to bridge and apply to virtually all of these transactions.
When you negotiate the acquisition of virtually any sophisticated software-controlled product, you should keep in mind the following issues which tend to be common across a vast range of such deals:
- Scope Creep: The buyer has to do more or buy more (or different) support systems than the buyer expected in order to install and operate the vendor’s equipment and software.
- System Warranties: The vendor warrants the performance of individual system components but not the performance of the system as a whole.
- Incomplete Performance Warranties: The vendor warranties do not warrant all features and functions desired by the buyer.
- Software Warranties and Remedies: Vendors often resist warranting their rights to license the software to the buyer. What if a third party alleges that the vendor’s software infringes the third party’s copyright or a court enjoins further use of the software?
- Does It Work: The vendor does not propose to acceptance test the completed system before turning it over to the buyer.
- Software Updates, Patches and New Releases: The vendor does not agree to provide software updates and patches for free, or to make new (and backwardly compatible) software releases available to the buyer at a pre-agreed price.
- Long Term Software Maintenance: The vendor does not agree to maintain software beyond any one year rolling warranty term.
- Availability of Spares and Peripheral Units: The vendor does not agree to continue to make spares and peripheral units (like CPE) available for a set number of years at stabilized or benchmarked prices.
- Long Term Dependability of the Small Vendor: Often buyers contract to use an important piece of software or equipment provided exclusively by a small vendor. Well, what if that vendor goes out of business? In this circumstance, the buyer may want to consider procuring rights of access to the software source code through a two-party or three-party escrow, a trust agreement or a source code license.
- Ownership of Custom Software: If any of the software is made to the buyer’s order in whole or in part, who will own that part that is made to order? The vendor, the buyer or both?
These are just a sampling of some of the more important considerations underlying the process of entering into a technology procurement transaction. How can you be sure that none of these common considerations is overlooked in the acquisition process? Generally, buyers have an easier time addressing these issues if the issues are specifically identified in the buyer’s request for proposal (RFP). Typically, the procurement process starts with an RFP which: (1) provides prospective vendors with knowledge of the buyer’s requirements; (2) better enables prospective vendors to suggest alternatives that may better suit the buyer’s needs; and (3) allows the buyer to better understand its needs and requirements for the procurement. An RFP process may seem like an unnecessary step, but a well-developed RFP can avoid misunderstandings and allow the buyer to negotiate key points early when the vendor is motivated to give concessions in order to win the project.
Buyers who choose not to use an RFP setting forth the buyer’s proposed material terms and conditions often find that the vendor expects the buyer to use the vendor’s documentation. In this event, the buyer can expect the vendor to provide a stack of brochures, tables and charts describing the product and its performance, along with one or more proposed standard-form agreements for the purchase and maintenance of the product. The vendor normally urges the use of its own standardized documents, often claiming that using those standard agreements will speed the process of concluding the transaction and reduce transactional costs.
From the buyer’s perspective, relying on the vendor’s standardized documentation is almost always a mistake. Agreements prepared by the vendor will tend almost without fail to include issues of importance to the vendor (and treat those issues, not surprisingly, in a vendor-friendly manner), while omitting legitimate concerns of the purchaser. This is not to say that the vendor is necessarily trying to put one over on the buyer. Rather, it’s an inherent limitation of vendor-supplied contracts, since the vendor knows itself and knows little about the buyer.
By contrast, when specific contractual terms and conditions are required by the buyer in an RFP, the vendor expects the buyer to demand a custom contract. And even if the vendor responds to the RFP with standard, vendor-created contract forms, the RFP can provide the buyer with a convenient checklist against which to analyze those forms. In that way the buyer can more easily determine when the vendor’s form contract does not cover all terms and conditions that the buyer regards as material (or does not cover them in an even-handed manner). In any event, buyers should not be shy about asking for custom documentation addressing the buyer’s concerns.
Some readers may now be wondering how they can address these issues and follow these suggested processes, yet stay within budget and the timeframe for the project? The answer is that competent counsel familiar with technology procurement transactions should be able to work with the buyer to focus on what is critical to the buyer. That counsel can also manage the process in a manner and at a cost consistent with the size of the project and the importance of the procurement to the organization.
