The contract negotiation
The timeframe for contract review should be sufficient to permit counsel to review and critique the contract.
Beware of vendors who, upon giving you a copy of the contract, tell you that any promised discounts require execution of the contract in a very short time period. Vendors know that the less time you have to understand the contract’s legalese, the less likely you’ll be to request changes and clarifications.
Identify up-front what could go wrong and the cost to the credit union if failure or delay does result. Review and negotiate remedies and damages with this exposure in mind.
A specific statement of work should be part of the contract. Exhibit 1 to any contract should contain the system specifications and include:
Be sure the statement of work, or another part of the contract, includes specific statements or representations made by the vendor regarding system function and capabilities that were important in selecting the particular system or vendor.
If they’re not explicitly in the contract, the “entire agreement” clause typically found in most IT contracts will render such promises unenforceable.
• Make sure the contract has a workable approach to test performance before “acceptance” of the system, and hold back a substantial amount of the purchase price until acceptance has occurred.
The acceptance concept in the law of contracting is important in that the buyer can reject the goods only before acceptance. After that time, the buyer is left to contractual remedies that are often very limited.
Testing must ensure the system works properly in a live environment and integrates into the credit union’s systems. A minimum testing period of 30 days is advisable.
Most warranties that are implied by law for goods contracts are typically disclaimed in software agreements. Certain functions or attributes of the system may have been fundamental to the credit union’s purchase decision and should be the subject of express warranties in the contract—for example, that the software is free of defects or viruses, the software doesn’t infringe on the intellectual property rights of third parties, and the vendor isn’t currently the subject of any litigation that will prevent it from performing under the contract.
• Scrutinize the contract’s remedy and damage provisions. Most courts will enforce these limitations against a purchaser absent fraud or complete failure of the vendor to implement the promised remedy.
Most of these clauses limit the remedy to repair or replace the system and limit damages to what the purchaser has paid for the system. Contracts typically exclude the recovery of consequential damages, such as lost business or the cost of labor to deal with the failure.
• Beware provisions that shorten the period for bringing claims against the vendor or select a court venue or law that’s unfavorable to the credit union.
• Be sure that the vendor has processes and procedures in place to absolutely secure and protect nonpublic personal information of credit union members. The vendor’s disaster recovery plan should also be reviewed.
• Review and negotiate indemnification provisions and allocate as much risk to the vendor as possible. Third-party claims should be carved out from any liability limitation.
Assign a team from the credit union that is charged with interfacing with the vendor on implementation.
Schedule weekly project implementation meetings with the vendor where a senior credit union officer not on the implementation team is present.
Be sure the credit union project manager is checking the implementation against the statement of work in the contract, including the project schedule.
There are many factors that affect IT project implementation success. However, careful product and vendor selection and informed contracting as described above can go a long way toward ensuring project success.