You're about to sign a contract for a core application. You've already reviewed the software's current and future capabilities, performed due diligence on the depth and knowledge of the vendor and its staff, checked references, and assessed the vendor's financial stability.
In my last column, I discussed the key terms and conditions your software vendor must include or define in the contract. So now you're all set to sign on the dotted line, right? Not yet. This column will discuss several other critical criteria you'll need to cover first.
1. Warranties and maintenance liability
What warranties or maintenance guaranties are expressed or implied in the contract? Be certain that they're clearly defined.
2. Regulatory changes and compliance
The contract must explicitly state that the software vendor is responsible for all regulatory compliance within the scope of its application.
[Looking to improve your digital business? Read Top 10 Retail CIO Priorities For 2014. ]
Remember that such compliance includes state as well as federal regulations. Your vendor might not have previously sold its applications in your state. This requirement is of particular importance with certain kinds of applications, such as payroll, credit card, and consumer-loan processing.
3. Computational errors
The contract should specify responsibility for computational errors (not input errors); for example, incorrect rounding. The contract must define computational errors, how soon your company needs to identify them, and the extent of financial compensation the vendor must pay in the event it makes computational errors.
4. Ownership of code
Does the vendor supply you with only the object code? If so, what's your position of ownership if your vendor reorganizes, files for bankruptcy protection, or goes out of business? Your company must retain complete rights to the source code.
5. Software interfaces
The contract should clarify the effect, if any, of other software interfaces on the vendor's system. For example, your company might want to develop, internally or through a contract programming firm, its own interfaces to other applications, such as general ledger and customer information systems.
Non-vendor interfaces might nullify parts of the warranty, particularly responsibility for computational errors.
6. Vendor releases
Does the vendor specify the number of releases it will issue during a given period of time? This contract provision usually isn't necessary, as long as the vendor upgrades in a timely manner. However, it's wise to include provisions that the vendor will provide software releases to meet federal and state regulatory changes and to keep current with market conditions.
Who's responsible for installing the releases? This issue is particularly important if your company intends to develop its own interfaces or modify the software. The last thing you want is your version to be "out of sync" with the vendor's standard.
How will the vendor support installation of a new release? Will it be onsite, remote, or a combination? What additional costs will your company incur for on-site vendor support?
Obviously, the extent of vendor support depends on your company's technology resources and the complexity of the release. Nonetheless, it's important to define in the contract the type and extent of vendor support. In fact, for a major application, your vendor should commit to a specific number of qualified people to maintain the system. For any large application -- a purchasing or deposit accounting program, for instance -- at least 10 people should be required.
7. De-conversion costs
This one is a bit unusual. Basically, you need to negotiate a set amount today for how much the vendor will charge your company when (or if) you de-convert from its system five years from now.
Vendors can charge some excessive (high-six-digit) de-conversion costs for simply handing over production files to another vendor. Those costs are typically two or three times the monthly operating costs then in effect. Consequently, you need to try to negotiate the cost for the equivalent of one month.
8. Training and education
Other than the system's functionality, training is the vendor's single most important offering. Make sure that the hours and quality of training and documentation are sufficient for all of the different functions.
The contract should specify the amount of training the vendor will provide, for both non-technology users and technical or systems personnel. The vendor should specify in the contract the amount, type, and location of the training, whether at the vendor's site, at your facility, or remotely, such as over WebEx.
The size and complexity of the application installation and conversion will determine the best mix of training and education. Most vendors will provide a substantial amount of education at its location at no charge.
For a large application or series of modules, the vendor should provide a remote production training application -- so that users can train on the system whenever time permits -- for free or at a nominal cost. All training that involves an instructor, whether on-site or on a vendor's premises, should have an associated cost. If your company exceeds the contractually allotted training time, the company would incur an additional charge.
In addition, stipulate in the contract that any "unused" training during a specific period (usually a year) gets credited to your account in the upcoming period or used to offset your company's software maintenance fee.
Ask for contract provisions that require the vendor to schedule and coordinate periodic user meetings or workshops. These events will help ensure that your maintenance payments go toward a system that's up-to-date.
9. Acceptance testing
Most software contracts don't provide a sufficiently complete definition of when a system or application is actually accepted by the customer. Before a company accepts a system, it must conduct an "acceptance test."
Such a test must involve processing actual company production data, not just vendor data. Acceptance testing occurs long before the actual conversion but after the physical delivery of the system. Depending upon the application's complexity and the scope of the conversion, a proper acceptance test can require 30 to 60 days.
Clearly, the entire contract depends upon a successful acceptance test. Consequently, if the application fails this test, the vendor must refund all money.
10. Service-level agreements
The contract must also spell out criteria for service-level agreements. The vendor’s adherence to SLAs will affect whether your companies continues with the software and the annual maintenance.
SLA criteria depend upon whether your firm processes the software in-house or in a service bureau operation. SLAs must define and quantify such factors as percentage uptime, availability, and response time.
If the vendor doesn't meet the SLAs, penalties include refunds, credits to future invoices, and even contract cancellation without prejudice. The contract must spell out the amount or percentage of penalties.
There's only one way for a company to ensure that it understands the contract and all of its ramifications: Study it!
InformationWeek Conference is an exclusive two-day event taking place at Interop where you will join fellow technology leaders and CIOs for a packed schedule with learning, information sharing, professional networking, and celebration. Come learn from each other and honor the nation's leading digital businesses at our InformationWeek Elite 100 Awards Ceremony and Gala. You can find out more information and register here. In Las Vegas, March 31 to April 1, 2014.