- Contract Tips for Systems Developers
by Peter Kelman, Esquire
Introduction
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.
Milestones
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.
Deferred
Payment
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.
Client
Obligations
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.
Legal
Boilerplate
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.
Conclusion
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's
· 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
Don'ts
· 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.