Don't sign on that dotted line until you review these critical criteria. Check out part two in our software contract series.
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.
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.
Bennett Quillen, a former CIO for a leading mutual fund processing firm, has more than 35 years of experience in financial industry technology, operations, cash management, and compliance. Today he provides financial institutions with project management and technology advice, ... View Full Bio
The Business of Going DigitalDigital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.