I recently corresponded with Thomas Hall, a legal practitioner who helps companies to implement IT initiatives and resolve disputes with IT Vendors.
Thomas works primarily for customers but also trains company personnel with his “contracts that work” philosophy.
Q. Please tell me a little about your background?
I have been practicing law for just over 20 years now. I spent my first 11 years as house counsel at Wausau Insurance, and have spent the last ten with different firms, both large and mid-sized. I started doing IT work at Wausau, in part because no one else wanted to do it and in part because it fascinated me. I still enjoy the challenge of identifying the customer’s business need, identifying possible solutions, and then putting in place a contract that will benefit both sides while preventing the project from “jumping the rails.”
Q. What common mistakes do clients make when signing software agreements?
In my experience the three most common are:
- Failure to identify the real need. For example, management wants “best in class email service.” Does that mean speed, speed and more speed? Encryption the military might envy? Or merely a better way to screen ads for porn sites and male enhancement products? If the customer does not clearly define what they need, or what they want to solve, it’s easy to spend lots of money without realizing tangible benefit.
- Failure to agree to acceptance testing procedures and performance standards that can be objectively measured. Hammering out the standards can be tedious, but they protect both sides. Vendor has a safeguard that it will be paid, even if customer gets cold feet, and customer will have hard evidence if the final product does not perform as agreed.
- Then, people often do not realize the contract, the written document, is also a tool in the management of the project. A well designed contract will cover the foreseeable risks, allocate risks fairly and contain mechanisms for dealing with surprises without having to resort to litigation. Litigation consumes time and money yet seldom yields a satisfactory result. It is also wise to tie payment to actual performance, not to calendar dates or X days after signing.
Q. How would you recommend reducing maintenance or license commitments mid-term?
I prefer that each license be fully paid up and perpetual, meaning that once the license fees are paid, no more are due in the future. Other things to guard against are licenses that limit the number of users, that specify users by name, or that limit the number, type or location of the CPU. Also, be sure that licenses can be transferred freely to new owners of the business. If customer does not have such a right, and then sells of Division X, the software vendor could demand additional fees before allowing the new owner to use the software.
Maintenance contracts require a hard look to determine what benefit is being received in return for the cost. Substantial fees should produce substantial benefits, such as real improvements to products released on a regular schedule and a discount on the price of new releases or versions. I regard bug fixes and security patches as part of the vendor’s cost of doing business. You might ask the vendor “What will happen if I don’t take out a maintenance policy?” If your IT staff can handle the situations vendor describes, or you believe the risk is acceptable, consider foregoing maintenance.
Q. What clauses would you recommend to protect, assist with and reduce the costs associated with software compliance audits?
To limit the likelihood of “fishing expedition” audits, I typically use language such as;
“Vendor may audit Customer’s compliance with this Agreement no more than once each year during the Term hereof. Such audits shall be:
* Conducted by properly trained personnel and in a manner designed to minimize disruption of Customer’s business operations;
* Restricted to those records, files and machines as are reasonably necessary to provide accurate verification of Customer’s use of the licensed software; and,
* Solely at Vendor’s expense.”
Vendors might respond “We need a right to audit more than once a year if we receive credible evidence of license violations,” and “If we discover a significant violation, Customer should pay for the cost of the audit.” These are commercially reasonable requests, but need not be “freebies.” If an audit discloses a violations, it may make sense for customer to pay for the audit cost, and pay the necessary additional license fees, but nothing more. Unless the audit discloses deliberate attempts to pirate vendor’s software, customer should not incur additional penalties.
Q. If an audit takes place, what should a client do from a contract perspective?
When the audit request arrives, set a meeting with your vendor rep and vendor’s audit manager to establish:
- When the audit will begin
- Who the auditors will be and agree what credentials they will provide
- What records they wish to see. This is the time to set forth what will and will not be available; what may or may not be copied.
- Ground rules (e.g. office hours, wearing badges, use of cafeteria, etc.)
- A dispute resolution procedure (e.g. the auditor wants files X Y and Z but the local manager does not want to provide).
- Set up your audit team and identify the leader
- Set aside space for the auditors
- Gather the files that have been requested
- Brief staff on appropriate interaction with the auditors (be polite, but refer all substantive questions to the audit team)
- Create a system to track when a file request is received, when the files were provided, and when they are returned. The auditors should sign for each file they receive. Customer rep should sign when files are returned.
The best response to an audit, however, is to maintain careful records of licensed and installed software and to actively enforce policies against the use of unauthorized software. If you know what you have “in house,” you will have no need to worry when the auditor knocks at the door. And, if you can present the auditor with complete records that answer all his/her questions, you may very well cut down the time needed for the audit.
If you have any further recommendations please contact me or post a comment below.
About Martin Thompson
Martin is also author of the book "Practical ITAM - The essential guide for IT Asset Managers", a book that describes how to get started and make a difference in the field of IT Asset Management.
On a voluntary basis Martin is a contributor to ISO WG21 which develops the ITAM International Standard ISO/IEC 19770.
Learn more about him here and connect with him on Twitter or LinkedIn.