What a software maintenance contract needs to cover

When you're negotiating a software maintenance contract, keep your priorities straight to ensure problems will get fixed

Dear Bob ...

I'm involved as the project manager for the implementation of a finance system, and I'd be interested on your take on something contractual, even though I know you're not a lawyer. The software is chosen, and the project is being planned in detail, but contracts are still being negotiated. One sticking point, and where I'm interested in your view, is on the question of warranties.

[ Have you encountered the technology pro's six greatest enemies? Send your memorable tale to offtherecord@infoworld.com. If we publish it, we'll send you a $50 American Express gift cheque. | Get a new tech tale delivered to your inbox every week in InfoWorld's Off the Record newsletter. ]

As standard for most software, this system is warranted for 90 days from go-live, but being a finance system, there are certain critical processes that won't have been run -- in particular, year end -- within that time frame.

Our negotiator argues that for as much money as we're paying, the software should be warranted for those processes too. The supplier argues that any issue like this would be covered under the maintenance agreement.

I reckon the practical impact of the difference is speed of response, possible direct costs to change something, and the supplier's undivided attention. I'm familiar with the "if I buy a car I expect it to work -- I don't pay upfront maintenance for that" argument and its counter of "external changes beyond its control," but I would be interested to hear your take on the issue.

Kind regards,

- Bamboozled

Dear Bamboozled ...

It seems to me there are two different circumstances that would require vendor attention in the circumstances you describe -- situations where the first real-world exercise of the software in question takes place outside the 90-day warranty. The first circumstance is that the software is defective: It doesn't do what it's supposed to do. The second circumstance is that the specs were wrong; the functions requested of the software turn out to be different from what your company really needs. There is no hard line separating these two circumstances, only a sizable swath of gray.

The first question to ask is what will happen when one of these comes up during the warranty period. I'm guessing the contract states that the vendor fixes software defects on its nickel, the law firm pays for the cost of specification changes and consequent additional programming, and in the case of dispute, everyone argues a lot, then ends up splitting the difference.

1 2 Page 1
Page 1 of 2