In other times the purpose of most contracts (and contract negotiations) was to define, to the satisfaction of the parties involved, how their anticipated business was to be conducted. The contracts spelled out, in straightforward terms, the significant benefits to -and responsibilities of - the signers.

How times have changed! If you have access to a software package license agreement I would suggest that you take a moment and review it. What can you really discern from the contract (and attachments) about how you and the software vendor will work together?

Chances are good you can spot the price in there somewhere among the legal disclaimers and generalities about system quality and performance. Would you be satisfied with your vendor relationship if what you see before you is all you receive?

If your contracts are unsatisfactory it\'s not that the contracts are at fault. Contracts are only written documents that mirror the understanding of men and women. It\'s the negotiation that preceded the contract that was lacking. We concentrate on the obvious, leave the important to the lawyers, and wonder why the contract is less than useful as a business document.

In concentrating on the price and the legal issues to the exclusion of most other considerations we sometimes do our companies a great disservice. We miss a tremendous chance to acquire tools that are essential to future schedule compliance, cost containment and vendor performance.

The typical mainframe software package, particularly in its early version, is a fabric of ideas, not a tangible product. Its ultimate usefulness depends on its ability to deliver function with less elapsed time and with higher quality than you can develop with your own staff. Will an extra 15 percent of the package price make any difference in this area? Will a stiff legal contract get a software product release out to you on schedule? Not likely.

What then does one negotiate? Certainly price, but also the delivered functionality of the base system. Certainly, a fair legal document, but also acceptance test criteria, product support levels, release contents, implementation and education support services. Contract negotiations are an excellent time to define the entire business environment surrounding your package implementation. Through contracts, system documentation, specifications, delivery schedules, and letters of specific understanding, an effective negotiator can provide a sound basis for subsequent project phases.

For example, look at a typical software product support agreement. It may promise a minimum number of product enhancement releases per year. What is the intended scope of each release (i.e., what level of benefit will your company receive)? What quality level will you find when your staff installs the release (i.e., will it do more harm than good)? In these documents the only unambiguous thing is often the annual fee and duration of the agreement. So what do we usually leap upon and negotiate? You guessed it - price and duration. No wonder product support has been, and continues to be, an area often abused by some in the vendor community. From ambiguous agreements comes ambiguous performance.

Removing ambiguities from license, product support and professional service agreements is difficult and time-consuming work. It requires candor and willingness to compromise on both the vendor and purchaser\'s parts. This good negotiation environment comes about when both parties realize that a clear understanding is ultimately beneficial to all. A strongly adversarial negotiating environment is both a detriment to this process and a warning signal to the buyer.

Ultimately it\'s the integrity and strength of the business relationship between the vendor and client - not the package price - that influences the outcome of the project. Let\'s work on that in our future negotiations and future contracts. We need a great leap backward to a time when contracts did more than gather dust.