by Peter Kelman, Esquire
Have you ever been caught in any of these situations:
You’re in the middle of a development contract with an important client; your client relationship seems good but the payments are coming very slowly; you’re not going to terminate the job, but what leverage do you have to accelerate payments?
You have developed a system for a client. Under your contract, you receive a large payment upon the client’s “acceptance of the system.” The client maintains the system has substantial errors and is not acceptable. Yet you know, despite the so-called bugs, the client is deploying the system in multiple locations and getting value from the system. How can you make the case that system deployment is the equivalent of system acceptance?
Assume these situations haven’t worked out and you are now in your lawyer’s office discussing the merits of filing a collection action against these clients. The lawyer asks you to help her understand whether your system is more like a car customized with accessories or a tailored suit altered to an unusual body shape. You sigh.
It is often said in systems development work that when you are three-quarters done with a project, another three-quarters remain. In today’s complex environment with multiple hardware and software platforms, system development is more demanding and uncertain than ever. Nevertheless, designing, developing and implementing a system may only be part of the battle, if you have not taken the time to develop a contract which protects you. After building your system, you do not want another three-quarters of your job to remain collecting your fees. This article discusses some provisions a developer should include in its client contract to insure a steady flow of payments, which when received, are reasonably certain to remain with you.
Do not enter into an agreement that describes your client engagement as one undifferentiated, all-or-nothing project. Rather structure your agreement to partition the project into discrete deliverables, or “milestones.” Typical milestones are based on either levels of functionality, stages in a project’s life cycle or the passage of time. The contract should specify a process whereby the work-product contained in a milestone is either accepted or rejected by the client, with a client’s silence construed as acceptance. Payments should become due with the acceptance of milestones. Once a client accepts a milestone, it becomes more difficult for the client to claim, at a later date, that the work contained in the deliverable was deficient.
If your contract conditions all or some of your payments on the client’s acceptance of your work-product, include language which permits partial payment for partial functionality. For example, if your system should process five types of transactions but only processes three, you should have a contractual basis for receipt of some percent of the retained funds. If the payment of significant sums of money is conditional on client acceptance, make sure your contract describes a mutually agreed upon process for assessing acceptance. If acceptance is the client’s determination, the process should require that you and the client mutually agree upon acceptance criteria prior to the client’s evaluation. Include a provision that allows a reasonable amount of time for you to cure any defects before the client is entitled to withhold funds.
If a client wants to defer some payments until the overall completion of a project, do not fight that concept. Instead, develop a cash-flow model which permits certain sums to be retained by the client. Specify that you will receive interest on the withheld amounts. If the project ultimately does not receive the overall approval of the client, the retained payments may be characterized as a “liquidated damages” making the client’s recovery of other monies more difficult. In the absence of such retained payments, a client may have an easier time recovering payments it has already made. If a substantial amount of money is withheld until project completion or milestone acceptance, argue to have the money placed in an escrow account. You will have an easier time recovering these sums if the client has parted with the money and has not earmarked it for other uses.
If the engagement requires client participation, be sure the contract contains a detailed description of the client’s responsibilities. You should not be penalized if you are prevented from completing a milestone because the client did not complete its assigned tasks. Unless the client task is explicitly listed, it will be “assumed” that the item was your responsibility and your bargaining position will be weakened. Don’t forget that client participation may be nothing more than the cooperation and availability of key client personnel. Unless you specify necessary levels of client assistance in your contract, you may find your project delayed due to a lack of expected support.
Last but not least, pay attention to the so-called legal “boilerplate” contained in many contracts. You should make these provisions work to your advantage. For example you should include an “integration” clause. Such a clause will be helpful in eliminating the “your word against my word” battle of oral representations. You should include disclaimer of warranties and limitation of liability clauses. In the absence of such a disclaimer and limitation, it is likely that a court would read into your contract the implied warranties found in the Uniform Commercial Code with attendant liabilities. Finally consider whether you want to specify an alternative dispute resolution process to prevent a larger entity from engaging in high-cost litigation and waging a war of attrition against you.
When entering into a contract for software development, think of the gears of a watch. As time progresses, each deliverable should ratchet the gears of payment forward and should not permit backward motion. Remember, the better you structure your development contract, the less likely you will be to participate in a meeting where people argue about whether your software is more like a custom car which can be resold or a custom suit which suit that may never have another buyer. You can respond, just read the contract.
Do’s and Don’ts of Development Contracts
- Do divide your overall deliverable into discrete milestones (time- or functionality- based)
- Do define a payment schedule tied either to time or to functional milestones
- Do define acceptance criteria for the partitions of the project
- Do put the onus on the client of stating that an individual partition is unacceptable
- Do specify a time limit within which the client must state deliverable deficiencies
- Do put in a cancellation provision, enabling the client to cancel the project with agreed upon notice
- Do provide for partial payment if a deliverable partially functions
- If the client insists, do defer a portion of interim payments as “retainage” until the project is completed; place deferred funds in an escrow account
- Do include a provision that unpaid bills will accrue interest
- Do regularly send invoices which include an interest calculation (you can always waive interest upon payment)
- Do have a limitation of liability and a disclaimer of warranties
- If over-all project acceptance is a condition for final payment:
- Do agree in advance on the criteria for acceptance
- Do require that some pre-defined level of use of the system is tantamount to acceptance
- Do time bracket the process of assessing project acceptance; it should start with an agreed upon act and end within a finite time thereafter
- Do require to the client to describe with particularity reasons for non-acceptance
- Do provide yourself with reasonable time to cure the problems if the project is not accepted
- Do argue for language that requires no more than “substantial” compliance of a project with its spec
- Do not undertake a project without a written contract; if the project is small, a letter agreement may suffice
- Do not agree to a contract with ambiguous terms of payment
- Do not agree to payment terms which significantly defer payment until the project is completed, without some procedural mechanism to resolve disputes
- Do not agree to terms which require a deliverable to be “bug free” before it is deemed acceptable
- Do not permit the client to assess acceptability in its sole discretion; establish a joint process to determine acceptability
- Do not agree to a provision which requires a refund of all monies paid, if at the end of a project the client deems the system unacceptable
Copyright 1999, Peter Kelman. All rights reserved.