Commercial buyers of information technology products and services are locked into a self-defeating pattern of behavior when it comes to negotiating contract terms and conditions with technology vendors, and it is time to move on to a better approach. Better technology vendor negotiations produce better contracts for a technology project, and better contracts produce better project outcomes. So, break the mold and move on to a better way of negotiating contract terms and conditions for your next technology project.
Vendor Contracts – Timing Is Everything
Let us assume that by now you have done a lot of planning and information gathering for your proposed technology project, you have completed a vendor selection process, and now it is time to document your deal with your chosen vendor.
At this stage in the technology procurement process, the most common practice—indeed the almost-universal practice—is to distribute the vendor’s proposed contracts to your project team for review and comment. Then, as if by instinct, everyone starts looking for vendor bias in the contracts. No one has been given this specific directive. You simply assume and expect that everyone knows the drill. Folks on your project team begin striking certain biased provisions and scribbling notes about amending others. For sure, removing or limiting vendor bias in the contracts is a worthwhile exercise, but now is not the time to perform this exercise.
Light bulb on
I had to get several technology deals under my belt before I realized this, but at this early stage of the contracting process, you really need to focus first on terms and conditions that are important to you, not the terms and conditions that are important to your vendor. We know your vendor has included in its specimen contracts (as modified prior to presentation to you) all the terms and conditions of your deal that are important to your vendor. In fact, they are very easy to identify. They are all the contract terms with vendor bias. These provisions are so important to your vendor that it has purposely added bias to them, often with obvious exaggeration and redundancy. Even if your vendor has to bargain down somewhat from these provisions, your vendor is still in a safe position because the starting point was so extreme.
What you should do instead
At this initial stage of contracting, you should ignore your vendor’s proposed contracts. Simply set them aside for the time being, and do this for two reasons.
First, in order to express in writing the terms and conditions that are most important to you, you must actually think of what those terms and conditions might be. Likeable as your vendor may be, your vendor will not have already added to its proposed contracts the terms and conditions most important to you for your particular project. You will have to come up with this stuff on your own.
Second, until you know what terms and conditions are most important to you
for your particular project, you are in no position to challenge your vendor’s biased provisions except in attempt to remove or limit the bias. “I don’t know exactly what impact this provision has on our project, but I know it’s not a provision that helps our cause.” Challenging these provisions in a vacuum does not really help you.
The big picture
Now is the time to start with a fresh, big-picture perspective, and then fill in lots of detail. Circle back to earlier stages of your procurement process and revisit your decisions, your assumptions, and the various things you have learned. As a result of your many meetings and discussions, there may be things that you are now taking for granted: special vendor qualifications, how a particular piece of your project will be orchestrated, acutely risky aspects of your project, and so on. Bring to mind other similar projects within your organization and apply what you learned from those experiences.
Re-acquainting yourself with prior thought processes, discoveries, assumptions, and experiences will help you remember aspects of your project that you previously deemed important—whether because they are critical to project success, they pose a substantial risk within your project, or perhaps both—and it will force you to consider the importance of other elements for the first time. This process will help you build out the terms and conditions for your deal that benefit and protect you, terms and conditions that maximize the probability of project success and minimize project risk.
As part of this process, make a detailed list of list of terms and conditions that are important for your particular project, and:
1) Categorize them by subject matter.
For example, requirements development and prioritization, data mapping, business process issues, software development, application integration, database integration, system integration, testing, implementation, buyer protections, vendor management tools, warranties, etc. When you get around to negotiating the items on your list with your vendor, your project team will have important reference points. “Does this contract item touch implementation? If so, let’s look at our implementation items.”
2) Add qualifiers for each item.
Among other things, qualifiers can include a ranking of particular item’s relative importance within your project (critical to project success, represents substantial risk, wish list, etc.). When you get around to negotiating the items on your list with your vendor, your project team will be less inclined to treat all items on your list as equally important. Almost certainly, not all will be equally important. Your team will have a sense of how hard to push on a particular item, and in terms of the give and take that occurs in any negotiation process, they will have sense of what items to compromise (and by how much) or concede outright if met by strong resistance from your vendor.
3) Add relevant notes and comments for each item.
Among other things, relevant notes to attach to your list items include comments about accountability. Who within your project will be accountable for accomplishing the particular item: your vendor, your internal staff, or some combination? And what should happen if the party with accountability drops the ball?
With this kind of list in hand, you are in a much better position to review your vendor’s proposed contracts. Perhaps most important, you are no longer reviewing the contracts in a vacuum. You are equipped to conduct a truly meaningful review of your vendor’s proposed contracts.
Is there a gap in the vendor’s proposed contracts; that is, an item from your list has not been addressed at all? Is there an inaccuracy in the vendor’s proposed contracts; that is, an item is addressed, but its present treatment does not match your understanding, preference or requirement? Are topics within the contracts miscategorized? Are interrelated items not treated as such? Are accountabilities not clearly established?
An even better approach
Although breaking the mold and adopting the above approach to technology vendor contracting will certainly help you produce better contracts for your next technology project, which contracts should facilitate a better project outcome, there is a way to help yourself even further.
Instead of starting with and working from your vendors’ proposed contracts for your next project, think about developing your own standard agreements to include within your technology procurement process (usually at the RFP stage).
First, develop a neutral or somewhat buyer-favorable Software License Agreement. Find a standard Software License Agreement and neutralize or remove the elements of vendor bias. Then add the buyer-side content that you would normally find yourself negotiating with a typical vendor (were you working from the vendor’s standard Software License Agreement). Next, find a standard Consulting Services Agreement and do the same thing.
You can add your newly-developed standard agreements to your next technology RFP and request that responding vendors either approve your standard agreements as-is, or cite alternative language for provisions they do not find acceptable.
By incorporating your standard agreements into your technology procurement process, you will achieve two important things. First, you will be able—probably for the first time—to evaluate vendor candidates based on one of the most important factors for project success, terms and conditions. You can guage a prospective vendors appetite for terms and conditions that are important to your for your particular project BEFORE you have selected a vendor. It is much harder to win favorable terms and conditions AFTER you have selected the vendor for your project. And second, you will greatly reduce negotiation cycle times.
More and more commercial information technology buyers—of all sizes—are using this approach. It may surprise you to learn that many reputable technology vendors will not only entertain the possibility of working from your standard agreements instead of theirs, they may even welcome the prospect because it saves them time and expense as well.
A word of caution
When you develop your own standard agreements, exercise some discipline. Do not convert a terribly vendor-biased agreement into a terribly buyer-biased agreement. This will not help your cause. Instead, shoot for balance. Software developers, for example, have to protect their rights in their intellectual property, and there a certain limits beyond which they will not venture; for example, an excessively broad license grant. Understand vendor limitations and be fair. Add buyer bias judiciously and only if it is truly important to your organization.
Meet Nuckles at http://www.NucklesLaw.com or visit the firm’s sister site at http://www.TechnologyBuyersAdvocate.com.
© 2008 All rights reserved. Olive Consulting Group LLC / Nuckles Law Firm
