When you are negotiating a deal with a software vendor, you should have several objectives in mind, and all of your objectives will fall under one of the following categories:
- Winning contract terms and conditions from your software vendor that serve and protect your interests; and
- Saving time and money during your vendor negotiation process and then during the working phase of your software project.
The following tips and suggestions will help you achieve the important objectives within each category.
You may also want to review these Software Licensing Tips.
Terms and Conditions That Serve and Protect Your Interests
You certainly want to get the best price for your software application and any required consulting services necessary to install, configure, integrate and implement your new application. But price is just one of many terms and conditions you need to consider. It's usually difficult to monetize the value of other important terms and conditions, but that's okay. Just accept that these other terms and conditions are valuable to protecting your interests and the success of your software project, and they can be invaluable should your project run into trouble.
License Owner
A standard license grant probably will not adequately match the structure of your organization. You may hold all techonolgy assets in your holding company, or you may hold them across the various entities comprising your organization. What entity within your organization should be the principal licensee of the software you are aquiring? Be mindful that later you may want to move ownership of this software to another entity within your organization for tax or other reasons. Even if your organization is comprised of a single entity now, you may want to assign the license to an entity you add down the road. Try to cover these ownership possibilities and eventualities now. See "Assignability" below.
Fee Basis
If you are buying a server-based license, your software vendor will want you to identify the loaded server and its physical location. Fine, but cover these other considerations as well. What if you want to load the software on a new machine at the same physical location in the future, and discontinue use of the software on the original server? What if you want to run the software from a different physical location? You'll want to cover these possibilities now and make certain that no additional license, change-out or other similar fee will apply when you do make such a switch.
What if the server to which you will load the software runs more than one CPU, and what if it runs one or more dual-core CPUs? You want to establish the license fee applicable to your particular server configuration. A single machine, regardless of number of CPUs or their nature, has become the accepted standard for a server'based license fee. If you do not cover (verify) this issue now, you may be in for some additional license fees after your first use audit.
You'll also want to cover additional server loads of the software at no additional additional charge. For example, you may want to have a non-production load of the software on a server for development purposes, and sometimes a load on an addtional server for testing purposes. You may want to load on a third server for back-up and disaster recovery (often at a different physical location). A software vendor will usually grant these addtional server loads so long as they are not used simultaneously for production purposes (something you'll have to represent and warrant to your software vendor).
If you are buying a seat-based license, and you are uncertain about the number of seats will you need in the coming months and years, think about negotiating tiered seat fees as opposed to paying a stated fee for each additional seat (usually more costly).
Avoid MIPS-based, instance-based, revenue-based and similar forms of licensure tied to some variable. One, you usually end up paying more than you otherwise would under these fee bases. Two, these fee bases are costly and annoying to administer. And three, if you sign up for one of these variable fee structures, your accounting function will be yelling at you down the road because your software fees are messing up their expense forecasting.
If your software vendor proposes one of these forms of variable-fee licensure, a good comeback is: "When I buy a wrench at Sears, Sears doesn't charge me an additional fee every time I use the wrench. I want a similar deal from you."
Permitted Use
In addition to what entity within your organization will own the particular software, you'll also want to establish who (what humans) within your organization can use the software and cover what affiliated entities in your organization may benefit from use of the software, whether the entities use it directly or benefit indirectly from centralized use of the software (as is the case with most forms of administrative software, such as an accounting package). Although it has different meanings in different contexts, licensure that provides unlimited enterprise benefit is often referred to as an "enterprise" license.
Integration Representations
If you are relying on your software vendor's representation that its application is "integrated" or "fully integrated" with, or "compatible" or "fully compatible" with, some other software application you are running (e.g., PeopleSoft, MS Office Suite, etc.), be sure to ask your software vendor to define these terms. In what sense is its software integrated or compatible with another application or suite? To what extent is it integrated or compatible? To what extent is the state of integration or compatibility relevant to your developed version of the other application? After you have defined the nature and extent of integration, make the integration representation part of the vendor's software warranties. If the integration issue is important or critical to your purpose, endeavor to test the integration with your actual version of the other software as it operates in your environment.
Warranties
Most standard software licenses are very weak on warranties. In fact, most licenses disclaim all warranties whatsoever, and an occasional license will warrant merely "conformance with the software documentation." You have to ask for and negotiate meaningful software warranties within a License Agreement.
You can start with a basic conform-to-documentation warranty and build upon that. Adding definitions to the License Agreement is a convenient way to start. First, you want to define the software "Documentation." Attach and include the then-current documentation as an exhibit to the License Agreement. To your new definition of Documentation, add things like the vendor's sales brochures, vendor PowerPoint presentations, demos, the results of use cases, etc. Whataver makes sense in your particular cirucumstances. If integration or compatibility with another of your applications is important, include that as a warranty. If your vendor will develop its standard base software for you to some extent, you'll want a number of warranties associated with the development effort.
Naturally, for any warranty you create in a License Agreement, you'll also need to provide for remedies in the event of breach. Software buy-back options are among the more potent and valuable remedies you might obtain. "System warranties" associated with development of software may allow you to recover all or some of the consulting expense you incurred for development if the developed software does not work as anticipated (does not conform to the enhanced set of warranties you negotiated.
For more information, see Software Warranties.
Indemnifications
Within a Software License Agreement, vendor indemnifications deal mainly with intellectual property rights. You are entitled to presume (and have your software vendor warrant) that it is the creator and copyright owner of the software for which it is selling you a license, and you are entitled to certain rights in the event someone alleges that the software infringes on someone else's intellectual property rights. In the event of an infringement allegation, you want your software vendor to defend you (and your use of the allegedly infringing software) at the vendor's expense, and until the dispute is resolved, you want continued use of the software or an alternative such that your operations are not disrupted during the pendency of the dispute.
Don't re-invent the wheel. Take a look at the vendor representations and warranties provisions, and the vendor indemnification provisions, in this Object Code Software License Agreement. Adopt and build upon these standard provisions and you should be in good shape in terms of indemnifications for your software license.
Support and Maintenance
Support and maintenance fees can be expensive, and they are a major revenue stream for software vendors. Consider whether you even need support and maintenance. Will you even implement any of patches and other fixes that your software vendor releases? If you or your vendor will develop the base software to any extent, it may be very difficult to implement subsequent patches and other fixes. Indeed, you may be able to cover normal bugs and glitches as part of vendor warranties, in which case your software vendor should provide fixes to problems you identify at no charge (at least for some stated time period, the "warranty period").
Because they are such an important revenue source for your software vendor, it may attempt to penalize you for not subscribing to at least some level of support and maintenance (e.g., by raising your license fee). The best practice is usually to negotiate a deal that includes at least the basic support and maintenance offering, and then dropping the support and maintenance later if that's best for you. Having spent a lot of time trying to sell you on its product, the vendor will be less likely to hammer you with a penalty for dropping support and maintenance late in the negotiation process.
If you do buy some level of support and maintenance, make sure support for your platform (e.g., Windows, etc.) will continue for the duration of the support commitment. You're not buying generic support. You want support that's relevant to your needs. Also, if you're not speedy in terms of installing updates, make sure your vendor will support up to two or three prior versions of the software.
Assignability
Make sure the assignability provisions of your License Agreement match your current and future assignability needs, as best as you can anticipate them. Most standard software licenses prohibit any assignment whatsoever without the vendor's prior consent. If you didn't cover assignability issues when you negotiated your original License Agreement, and now you want to assign, you can count on paying one or more additional fees. Your vendor holds all the cards.
Saving Time and Money
Again, you want the best price for your new software application and any associated services. Plain and simple. But you also want to minimize the time and associated internal expense you spend on negotiating your software deal. The following tips and suggestions focus on saving time, and so money, within your software vendor negotiation process.
Keep Three or More Finalists in the Running
In terms of winning favorable pricing and for other important reasons, keep at least three qualified software vendors in the running during your negotiation process. This is not always possible, but usually it is. Even if you have identified one of the remaining vendors as a front-runner, they don't need to know that just now.
Each finalist need not know for certain that other vendors are still in the running, but your conduct during negotiations will usually offer clues. If a vendor asks about competitors, you should not lie. You can volunteer that you're still talking to other vendors, but you should refuse to name them (that just invites Ford is better than Chevy pitches from your vendor).
Using Your Own Standard Agreements
You can develop your own neutral or slightly buyer-favorable Software License Agreement and Consulting Services Agreement and attach them to your RFP for your software acquisition. Well, basically, all of the stuff above under "Terms and Conditions That Serve and Protect Your Interests."
For example, with respect to License Owner, prefill all of your unique detail in the license grant portion of your standard License Agreement. Same for Fee Basis, Permitted Use, and so on.
You can save an incredible amount of negotiation time by using you own standard agreements. And, just as important, after you have whittled down your vendor candidate list to 3-5 possibles, you can use a vendor candidate's acceptance of your terms and conditions as an actual selection criterion when making your final vendor selection. It's much more difficult, and time consuming, to negotiate terms and conditions AFTER you have awarded your project to a chosen vendor. A vendor candidate may not accept each and every one of your preferred terms and conditions, but you will have substantially narrowed the field.
Negotiation Teams
You will want to require that your software vendor include an authorized decision maker (with binding authority) in all in-person meetings and conference calls. Otherwise, you will face the classic negotiating tactic of "refer to higher authority." Referring to a higher authority gives your software vendor additional time to come up with reasons why in cannot accomodate your particular request, and it always delays the negotiation process. Be aware, however, that if you require this of your vendor, it will probably require the same of you.
Requiring continuity of your software vendor's negotiation team from one negotiation session to the next is also a good idea. You won't waste time bringing a newbie up to speed, and you won't have to keep repeating, "We've already covered that numerous times."
Controlling Negotiations
You can expedite your negotiation process and obtain other benefits by controlling the negotiation process with your software vendor. You don't have to (and shouldn't) control the process in a Machiavellian way. You can control the process in subtler ways that are more effective, but control can be very valuable. Think of it this way. It's your software project, and it's your money being spent. Why shouldn't you be entitled to control the negotiation process (in a fair and responsible way)? You are the buyer, and you are "buying" as opposed to "being sold."
For example, your staff should take it upon themselves schedule all negotiation meetings and conference calls and follow-ups. Your inside or outside legal counsel should draft all rewrites of contracts that are being negotiated, and turnarounds to the other side should be very prompt (the same or next day) in order to keep the momentum of negotiations at a peak. A leader on your negotiation team should emerge as such early on in the negotiation process, and if you'll use a good cop/bad cop routine, your negotitation leader must always be a good cop.
Walking Away From Negotiations
In many negotiation settings, including software negotiations, there often comes a point when further discussion just breeds more disagreement. If your top-ranked vendor is intractable on a deal-breaking issue, you must have an overall fallback option, including initiating negotiations with your second-ranked vendor. When you reach a stalemate, your lead negotiator should:
- Suspend negotiations to give both parties time to reconsider their options (clear the air);
- Later resume negotiations and attempt to resolve the contentious issue;
- Notify the vendor that you will terminate negotiations and initiate negotiations with the second-ranked vendor if the top-ranked vendor remains contentious on a deal breaker issue; and
- Terminate negotiations outright if the vendor is still intractable.
Willingness to negotiate may have been one of the reasons for selecting the top-ranked vendor. You now know that you scored this vendor incorrectly on this criterion. It is now desirable to start negotiations with the second-ranked vendor. Naturally, if you haven't left yourself with a second-ranked vendor, you are now in a tough position. Bluffing is an option, but be mindful of ethical considerations.
© 2008 All rights reserved. Olive Consulting Group LLC / Nuckles Law Firm