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