Issues for Local Governments Contracting for New Business Software Applications

The Contract with the Software Integrator

This is where the “heavy lifting” is done from a legal perspective in software conversion projects.  Both the integration vendor and their client have important responsibilities in making a project like this successful.  It is important that the contract documents are balanced, accurately reflect each party’s responsibilities, and are sufficiently detailed to minimize the risk of disputes.

Typically, the contract documents include (i) a Master Services Agreement (an umbrella agreement) and (ii) one or more Statements of Work that address the technical, management and other specifics of  the project in more detail.  Here are some of the issues that must be addressed in those contract documents.

• Payment terms – fixed prices, or time plus expenses.  Under a fixed price structure, the integrator is due certain payments upon reaching certain milestones in the project.  Or they can be paid on a time plus expenses basis.  There are pros and cons to each approach, and each should be evaluated.
• Warranty, and Assistance with Software Bugs.  Perhaps the biggest potential pitfall is getting caught between the software provider and the integrator if there are problems after the installation.  Typically, the integrator will warrant their work product and services for a period of several months after the “go live” point that a software application is put into use.  But the integrator’s warranty will not cover software bugs, which are the responsibility of the software provider.  The risk of getting caught between them on a problem can be mitigated by getting a commitment from the integrator that, if there is a software defect, the integrator will exercise all commercially reasonable efforts to assist in resolving the problem, including inter-facing with the software provider on behalf of the client, or workarounds or patches on the baseline software version to help maintain the project schedule while a solution is worked on.
• Detailed testing procedures, and criteria for putting software into production.  The contract documents (usually the Statement of Work) should include detailed phases for testing software.  There are universally recognized categories of software defects, based upon the severity of the defect.  The criteria for “going live” with the software should be based in part upon those defect criteria.
• Approval of key personnel and subcontractors. The client should have the right of approval of the integrator’s key personnel on the project, and even some ability to require replacement  of a non-performing employee of the integrator’s assigned to the project.  The client should likewise have the right to approve of any subcontractor in advance.  The contract documents should include a list of obligations applicable to both the integrator’s employees and subcontractors while at the client’s site. 
• Minimum insurance.  Software integrator’s typically are not bonded, but agree to maintain minimum levels of insurance during a project.  These will not be in their standard contract, so they need to be added.
• Limited remedies and caps on liability.  Integrators often expect the client’s remedies to be limited to re-performance of any defective services within a cure period, or a refund for the defective services; and a cap on their overall liability for breach of contract, with an exclusion for any consequential damages (e.g., lost profits).
• Change Order process.  It is important to have a detailed change order process agreed upon. 
• Termination.  The client may want a right of termination for convenience.  The integrator’s responsibilities in the event of termination prior to completion of the project, in transitioning to another integrator, should also be spelled out.
• Dispute resolution.  It is good to have a tiered approach, where dispute resolution starts with the parties’ project managers and escalates up each side’s organization if unresolved.  Arbitration clauses are common in these agreements, the client’s location as the venue for any arbitration, and the client’s state law applying.

The Software License Contract

Perpetual software licenses and related support are purchased either directly from the software provider, or its authorized distributor, using the software provider’s standard contract.  Relatively speaking, this is the easier contract to negotiate, because software providers are typically very reluctant to deviate from boilerplate terms in their contracts.  Nevertheless, the issues in negotiating such contracts include the following.

• Price holds for additional software.  Software pricing can be complex, based upon the number of  users of the software, and annual revenue or utility customer base.  If a project is undertaken in phases, price holds for software needed after the initial phase can be obtained.
• Use of software to provide services to other entities.  Most software licensing contracts limit its use to the buyer’s operations.  If a utility envisions providing services to other local government utilities, this limitation can be an issue and additional fees may have to be paid.
• Results of an audit of use of the software.  Audits by software providers of use of their software for compliance with the licensing terms is not uncommon.  The contracts typically provide that the software provider can terminate support if an audit reveals additional fees for software usage are due, which are not timely paid.  The client will want to reserve the right to contest the audit results without losing technical support while the issue is resolved.
• Choice of law and venue for disputes.  Software providers typically have their state law apply, and their state as the venue for resolving any disputes.  If they do not agree to changing this to the client’s state of residence, they may agree to change it to some neutral state.