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@freibrunlaw.com.