Should you pay for your vendor's development environment? If you're not sure, you're not alone. Many IT procurement managers fail to answer this question correctly. The answer depends on the nature of work the vendor is supposed to do. Failing to understand when you have to pay - and when you don't - can set you up for a fleecing.

Addressing the issue during negotiations, rather than after you've given a vendor the go-ahead to build your software, avoids the potentially costly gotcha, "Oh, by the way, we have to talk about the development environment costs."

The rule of thumb for development environment responsibility is this: If the software you want developed requires a unique environment, you'll probably have to pay for it. And if you do pay for it, make sure you own it. If it's not very unique, don't pay the environment costs. If you're having development done in a standard environment that the vendor already has in place, you shouldn't pay for it. A standard development environment is a vendor's cost of doing business and should be included in its rates.

In some deals, customers can provide actual components to vendors. If you do, it's important to make sure you own the components or have the right to allow the vendor to use them.

Make sure that any software license you provide allows a third party, such as the software developer, to use it on your behalf. If you lease development equipment, make sure you have the right to relocate it and allow the vendor to use it on your behalf. All of this may seem like trivia, but it could be costly if it's overlooked. Your development agreement should also provide for the timely return of all the development environment components you provided.

If you plan to enter into a longer-term maintenance/ support agreement with the development vendor, make sure you obtain the right for a third party to use your components during an extended period of time. Some licenses allow only short-term use. If the third party is a direct competitor of the licensor, it will be more difficult to obtain an extended right of use. If you're not providing the components to the developer - but the developer is acquiring them for the project, and you're paying for them - be sure all your ownership or licensee rights are acquired and assigned to you.

The key to this puzzle is understanding and agreeing up front what's standard and what's unique. The vendor should be responsible for the standard stuff, and you should be responsible for the unique stuff. Regardless, make sure you're getting what you're paying for - or not paying for something you're not getting.

Mail Bag

In my Sept. 4 column, I ran an e-mailed question from Mike, a vice president of a regional bank who asked for input on a few vendor liability and accountability issues.

Here's a good suggestion from Greg Hopkins, who's with the procurement department at Allstate Insurance Co.: "What I've been able to do is to require the supplier to purchase errors and omissions [E&O] insurance [professional malpractice insurance that covers damages caused by the insured's failure to perform as represented]. We try to set the coverage limit to fit the size of the deal. Then, in the liability section of the contract, we make a statement about recouping any fees, not to exceed the E&O limit, for errors. This would provide the supplier with a means to pay for the liability claim."

Thanks, Greg and Mike! Watch for more reader suggestions.

Joe Auer is president of International Computer Negotiations Inc. (http://www.dobetterdeals.com/), a Winter Park, Fla.-based consultancy that educates users on high-tech procurement. ICN sponsors CAUCUS: The Association of High Tech Acquisition Professionals. Contact him at joea@dobetterdeals.com.