Software Development Agreements: Put it
in Writing, Part I
By Eric S. Freibrun, Esq.
I meet many of my clients after
they’ve been on one side or the other of a software development project begun, and
sometimes completed, without a detailed written agreement. Either the scope of the project
has expanded, or the complexity of the work was underestimated, and the developer winds up
performing additional work the user doesn’t want to pay for. Or the user, assuming it
owns the software it paid the developer to code, objects to the developer providing a
modified version to one of the user’s competitors. Or the developer, assuming it owns
the software and only gave the user the right to use it for the user’s internal
business purposes, objects to the user’s efforts to commercially distribute the
software -- without royalties to the developer. And on and on.
The cost of a failed or disputed software
development effort can be extremely high for both the user and the developer. The user has
often paid substantial sums to the developer and may sue to recoup those costs if the
system does not perform as intended. The time lost in an unsuccessful development effort
could severely effect the user’s business operations, which may entitle the user to
recover consequential damages from the developer. Similarly, the developer may be
expecting to receive a significant fee which it may have to sue to recover if the user
disagrees with the developer as to what was supposed to be delivered.
Get a Written Agreement
Without a comprehensive written agreement
governing the arrangement and serving as a blueprint for the development effort, it’s
one side’s word against the other’s as to what the parties originally intended.
Further, whether the project involves custom original code, third party application
software, customization of existing programs, or some combination of all three, it is
essential to clearly state the parties’ respective intellectual property ownership
and licensing rights. This is a very complicated task best not left to the user’s
Director of Marketing or the developer’s V.P. of Sales (each experts in their own
fields) who may wish to personally savor the joys of contract drafting and save on legal
expenses.
Documenting the Development Process
A complex custom software development
engagement is often divided into several distinct phases: preparation of preliminary
functional specifications, preparation of detailed design specifications, software coding
from the detailed specifications, data conversion to the new system (if it replaces an
existing one), and acceptance testing. Each should be reflected in the overall written
agreement.
The preliminary functional specifications
serve as a high-level blueprint identifying, in non-technical business terms, the needs
the user expects the system to address. In many cases, they will have been prepared by the
user and included in a Request for Proposal. If the developer believes the specifications
are unrealistic, it should persuade the user to modify them at this early stage, before
development is begun. The developer should not agree to design a system to conform
precisely to the preliminary functional specifications. The software may evolve during the
development process into a different form than originally envisioned by either party.
Nevertheless, the developer should expect that the user will want the preliminary
functional specifications to become part of the contract and may require the user to agree
that the software will "substantially perform" the stated business functions.
While the preliminary functional
specifications will in many cases have been prepared by the user, the detailed design
specifications will usually be prepared by the developer and build upon the preliminary
functional specifications. They will typically include flowcharts, system documentation,
descriptions of output, examples of the user interface, telecommunications requirements,
data and file layouts, documentation requirements, acceptance test criteria and schedules.
The contract should provide that the user will have a specified period of time, such as 30
days, to review and either approve or suggest modifications to the detailed design
specifications. The user should have the right to terminate the contract if it is not
satisfied with the specifications produced by the developer. On the other hand, if the
developer is asked to include additional features and functions, the user should expect to
pay additionally.
Most users will insist that a development
and implementation schedule be included in the contract. The developer will often have an
opportunity to shape the schedule in situations where it is more familiar with the
development process than the user. The schedule should provide for weekly status meetings,
so as to avoid any surprises from almost inevitable delays. Schedule slippages typically
result from the user requesting design changes, changing developer staffing demands,
unavailability of key user personnel for decisionmaking, or unavailability of other
resources. The contract should state the respective efforts and levels of contribution
required of each party in order to meet the schedule. Since slippages are to be expected,
the developer will want to avoid agreeing to financial penalties associated with delays
and may wish to agree to exercise only "best efforts" to meet the schedule. If
the user insists on a rigid schedule plus penalties for delays, the developer should
negotiate to receive bonuses for early delivery.
The acceptance testing process typically
involves testing each software module individually, and the entire system as a whole, to
determine whether it conforms to the detailed design specifications. The testing mechanism
should be set forth in detail in the contract. It should state objective acceptance
criteria which can be developed with the assistance of an independent third party if the
user and developer cannot agree on what such criteria should be. From the developer’s
standpoint, the contract should require the user to provide written acceptance or
rejection of the system within a specified time period, or it will be deemed accepted. The
developer should be afforded several opportunities and reasonable time periods to correct
any defects that may cause the system to fail the acceptance tests before the user can
consider the developer to have breached the development agreement.
Next month: payment provisions, ownership
rights, warranties and limitations of liability.
Attorney Eric Freibrun specializes in
Computer law and Intellectual Property protection, providing legal services to information
technology vendors and users. Tel.: 847-562-0099; Fax: 847-562-0033; E-mail: eric@freibrun.com.
Copyright © Eric S. Freibrun, Esq., Law Offices of Eric S. Freibrun, Ltd. All rights
reserved.
