Business buyers of information technology products and services are trapped in a self-defeating pattern of behavior when it comes to negotiating contract terms and conditions with technology providers, and it’s time to move on to a better approach. Better negotiations with technology providers produce better contracts for a technology project, and better contracts produce better project results. So break the mold and move on to a better way to negotiate contract terms and conditions for your next tech project.

Supplier contracts: timing is everything

Let’s say you’ve already done a great deal of planning and information gathering for your proposed technology project, have completed a vendor selection process, and now it’s time to document your dealings with your chosen vendor.

At this stage of the technology acquisition process, the most common practice, indeed the almost universal practice, is to distribute the vendor’s proposed contracts to their project team for review and comment. Then, as if by instinct, everyone starts looking for vendor bias in contracts. No one has been given this specific directive. You just assume and hope everyone knows the drill. People on your project team begin to eliminate certain biased provisions and write notes on changing others. Eliminating or limiting vendor bias in contracts is certainly a worthwhile exercise, but now is not the time to do this exercise.

light bulb on

I had to get several tech deals under my belt before I realized this, but at this early stage in the contracting process, you really need to focus first on the terms and conditions that are important to you, not the terms and conditions that are important to your vendor We know that your vendor has included in its model contracts (as amended before submission to you) all the terms and conditions of your agreement that are important to your vendor. In fact, they are very easy to identify. They are all contract terms with vendor bias. These provisions are so important to your provider that you have deliberately added them biased, often with obvious exaggeration and redundancy. Even if your provider has to trade a bit below these provisions, your provider is still in a safe position because the starting point was so extreme.

What you should do instead

At this initial contracting stage, you should ignore the contracts proposed by your supplier. Just set them aside for now, and do so for two reasons.

First, to put in writing the terms and conditions that are most important to you, you need to think about what those terms and conditions might be. As nice as your supplier is, your supplier will not have already added to their proposed contracts the terms and conditions most important to you for your particular project. You’ll have to make these things up on your own.

Second, until you know which terms and conditions are most important to you for your particular project, you are not in a position to challenge your provider’s partial provisions, except in an attempt to eliminate or limit bias. “I don’t know exactly what impact this provision has on our project, but I do know that it is not a provision that will help our cause.” Questioning these provisions in a vacuum doesn’t really help you.

The panorama

Now is the time to start with a new overview and then fill in with lots of detail. Go back to earlier stages of your procurement process and review your decisions, your assumptions, and the various things you’ve 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 part of your project will be orchestrated, highly risky aspects of your project, etc. Think back to other similar projects within your organization and apply what you learned from those experiences.

Reacquainting yourself with previous thought processes, discoveries, assumptions, and experiences will help you remember aspects of your project that you previously considered important, either because they are critical to the success of the project, represent a substantial risk within your project, or perhaps both. . -and will force you to consider the importance of other elements for the first time. This process will help you develop terms and conditions for your agreement that benefit and protect you, terms and conditions that maximize the likelihood of project success and minimize project risk.

As part of this process, make a detailed list of the terms and conditions that are important to your particular project and:

1) Sort them by theme.

For example, requirements development and prioritization, data mapping, business process issues, software development, application integration, database integration, system integration, testing, implementation, buyer protection, vendor management tools, guarantees etc When you get to negotiating your list items with your supplier, your project team will have important reference points. “Does this contract article touch on implementation? If so, let’s see our implementation articles.”

2) Add qualifiers for each item.

Among other things, qualifiers may include a ranking of the relative importance of a particular item within your project (critical to project success, poses substantial risk, wish list, etc.). When you get to negotiating your list items with your vendor, your project team will be less inclined to treat all your list items as equally important. It is almost certain that not all of them will be equally important. Your team will have an idea of ​​how difficult it is to push on a particular item, and in terms of the give and take that occurs in any negotiation process, they will have an idea of ​​which items to compromise (and to what extent) or concede entirely. if you encounter strong resistance from your provider.

3) Add relevant notes and comments for each item.

Among other things, the relevant notes to attach to your list items include comments about responsibility. Who within your project will be responsible for achieving the particular item: your vendor, your internal staff, or some combination? And what should happen if the responsible party loses the ball?

With this type of list in hand, you are in a much better position to review your supplier’s proposed contracts. Perhaps most importantly, you’re no longer reviewing contracts in a vacuum. You are equipped to perform a truly meaningful review of your supplier’s proposed contracts.

Is there a gap in the contracts proposed by the seller? ie an item in your list has not been addressed at all? Are there any inaccuracies in the contracts proposed by the seller? i.e. an item is addressed, but its current treatment does not match your understanding, preference, or requirement? Are the topics within the contracts miscategorized? Are interrelated items not treated as such? Are the responsibilities not clearly established?

An even better approach

While breaking the mold and taking 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 you further.

Instead of starting and working from your vendors’ proposed contracts for your next project, consider developing your own standard agreements to include within your technology procurement process (usually at the RFP stage).

First, develop a neutral or buyer-friendly Software License Agreement. Find a standard Software License Agreement and neutralize or eliminate elements of vendor bias. Next, add the buyer-side content that you would normally find negotiating with a typical vendor (if you were working with the vendor’s standard Software License Agreement). Next, find a Standard Consulting Services Agreement and do the same.

You can add your newly developed standard agreements to your next technology RFP and request that responding vendors approve your standard agreements as-is or cite alternative language for provisions they find unacceptable.

By incorporating your standard agreements into your technology acquisition process, you will accomplish 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 the success of the project, the terms and conditions. You can gauge potential vendors’ appetite for the terms and conditions that are relevant to your particular project BEFORE selecting a vendor. It is much more difficult to obtain favorable terms and conditions AFTER you have selected the supplier for your project. And second, it will greatly reduce trading cycle times.

More and more commercial information technology buyers of all sizes are using this approach. It may surprise you to learn that many big-name technology providers will not only consider working with their standard agreements instead of theirs, but will even welcome the prospect because it saves them time and money.

A word of caution

When developing your own standard agreements, exercise some discipline. Don’t turn a terribly vendor-biased deal into a terribly buyer-biased deal. This will not help your cause. Instead, find balance. Software developers, for example, have to protect their intellectual property rights, and there are certain limits beyond which they will not venture; for example, an excessively broad license grant. Understand the limitations of providers and be fair. Add buyer bias judiciously and only if it’s really important to your organization.