Do’s and Don’ts for Your Software Development Contract
Software development projects can be the source of very expensive and contentious disputes. Projects may fall behind, requirements may change, and may be personnel turnover. This makes the terms of the contract governing the project vitally important. A software development contract that does not lay out the precise expectations of the parties becomes one open to interpretation by non-parties who will likely not be technical experts. This article lays out tips for both companies purchasing software and companies that provide software, to assist them in creating an enforceable software development contract and a successful software development project.
DO: Assemble the Project “Dream Team”
Before contract negotiations begin, both the purchaser and the software company should establish the best project teams possible. A balanced project team will ensure that the contract is as clear as possible – and has the terms you want and need. Each organization possesses its own dynamics, but there are some general guidelines to ensure you assemble a strong team.
Both the purchaser and the software company should have teams with at least one person who can understand the technical issues and communicate effectively with the business personnel. The software company’s team should have a non-sales business person involved who can understand the technical language, as well as a technical person (or team). Having these effective communicators, as well as people with technical expertise, on both teams, will ensure that the purchaser’s requirements are more clearly understood.
Another important member of each team is an attorney (or attorneys) – either in-house counsel or outside counsel. Attorneys can ensure that the contract is completed with as little risk as possible, in the event something goes wrong. With large and complex software contracts, it is not uncommon for something to go awry.
Finally, ensure that the correct decision maker and financial expert are part of the team. Having a decision maker who can dedicate time to the project will ensure that well-informed decisions are made in a timely fashion. The financial expert can assist with modeling the effects of various payment structures, an important consideration for both companies.
DO NOT: Rush Through the RFP Process
If the project is large enough, or if it is the purchasing company’s normal practice, the purchaser may issue a request for proposal (“RFP”), soliciting information and bid from various software companies. The following are a few guidelines that both purchasers and software companies should follow during the RFP process.
Software purchasers should make their RFPs as detailed and as accurate as possible. A detailed RFP will ensure that the responding software companies understand the high level project requirements. The RFP should also ask the software companies to provide information that includes: (1) a statement regarding communications, including whether there will be regular meetings and who must be involved in any changes in requirements or specifications; (2) technical specifications, including, for example, what data inputs the system will use, and what reports can be created, what the next version of the software may look like, etc.; (3) the estimated cost; and (4) an estimated timeline of milestones and deliverables. The RFP should provide software companies with ample time to give meaningful responses. Further, the RFP should include any contractual provisions that the software purchaser knows will be in the final contract, such as provisions regarding acceptance testing.
The software company’s RFP response should be as detailed as possible, so the purchaser understands the software company’s capabilities. The software company will likely be legally bound by the RFP response, so it is important for the software company to investigate its abilities (e.g., employees available, development skills) and be as forthcoming as possible.
Attorney involvement in the RFP process is important. An attorney can assist in determining the correct language for the RFP and/or the RFP response; both of which will likely be incorporated into any final contract.
DO: Include a Clear Purpose in your Contract
The purpose is at the very beginning of the contract and it should clearly and succinctly explain what the software will do. Everything in the contract should fall within the “purpose” and go toward that purpose. The purpose informs a later party reviewing the contract, such as a judge, what the parties intended when they entered into the agreement.
For example, if the purpose reads, “This is a contract for the development of software to fully replace Purchaser’s existing payment processing software,” this purpose can protect a purchaser if the software does not live up to the intent expressed – e.g., to be a replacement for a prior system. It can also protect a software developer, if the purchaser later states that the software should have had functionality that could not have been contemplated by the intended purpose – e.g., functionality not present in the purchaser’s existing software.
The details of the contract may expand or narrow the purpose as needed (e.g., the details of the contract may explain that all elements of the prior software are being replicated in the new software except for “x, y, and z”), but the purpose can help inform the parties, the court, and any jury, as to what the contract covers.
DO NOT: Ignore the Potential for Disputes
Parties negotiating a new deal often do not like to think about what may go wrong. However, it is a significant mistake to omit a dispute resolution provision. Dispute resolution provisions can lay out the steps the parties must take to solve their problems before filing a lawsuit. The provision can specify, for example, that, first, the parties meet in person (or via teleconference) at least three times to discuss the issues. Then, the executives from both companies sit down at the table together. Finally, only after attempts at discussions go nowhere, a complaint may be filed in arbitration or in a specific court—whatever the parties desire.
Spelling out these dispute resolution steps is especially important in software contract agreements. Software contract disputes often involve highly technical information. No matter where the dispute ends up, whether arbitration or the courtroom, it will be very likely be necessary to explain technical information to a layperson. That may mean explaining it to a magistrate judge or a mediator for settlement purposes, to a judge on a motion to dismiss, to a jury during trial, or to an arbitrator during arbitration. Due to the technical nature of these contracts, parties may want dispute resolution procedures that allow them to avoid explaining the technical information to laypersons for as long as possible.
Keep in mind that it is not only the software company that has to worry about conveying technical information. If the purchaser feels the contract was breached, it is the purchaser that has the burden of explaining why the software developed does not meet the requirements set forth in the contract, which would likely involve technical explanations.
DO: Carefully Draft Requirements
The requirements are the center of any software development contract. They detail what is to be developed; what features the software will have. High-level requirements should be put into the contract before it is signed. The detailed requirements can be incorporated after the contract is signed, but there should be a section in the original contract stating that: (1) requirements are to be developed, (2) those requirements will be detailed and in writing, (3) the requirements will be incorporated into the contract, and (4) the requirements are due by a particular date. Having detailed requirements, in writing, ensures that the parties will fully understand what software is to be developed. There is a risk that the parties may not agree on detailed requirements, which may foreshadow disputes in the future. It is for the benefit of both parties to agree to as many requirements as possible.
There should also be a provision regarding changing requirements. There may come a time when previously agreed-to requirements must be changed. Perhaps the parties learn something about the existing system that they did not know before. The contract should contain a provision stating whether requirements may be amended, and the process for amending them.
The requirements provisions should answer questions such as: Do both sides need to sign off on the requirements? How are requirements changes communicated? Will regular meetings be held to ensure that the requirements are on schedule? Who is involved in this process? Does the reason for any requirements change need to be specified in writing?
DO: Define “Acceptance”
Consistent in every software development contract is the need for a definition of what constitutes acceptance of each project milestone and what constitutes acceptance of the entire software. Often, payment at each milestone will be due upon the purchaser’s acceptance. Parties frequently fail to clearly define what actions or criteria constitute acceptance, which gets them in trouble.
The definition of acceptance will vary depending on the type of software and the parties’ priorities. There are a variety of questions that need to be answered when considering the definition of “acceptance,” including: Will acceptance testing be used? If so, what passage rate will be deemed to be acceptance? Will acceptance be made in writing? Are any test cases dictated by the purchaser or the developer? How many test cases must be run?
The importance of acceptance criteria, and the terms relating to acceptance, are further reasons to include a lawyer in all of the contract negotiations. In a case from the Seventh Circuit, the court found that there was acceptance of the software system, despite the purchaser’s silence regarding the results of testing. Micro Data Base Sys. v. Dharma Sys., 148 F.3d 649, 655-656 (7th Cir. 1998). The court awarded the software developer the balance of the contract it was due, given the other party’s acceptance. Id. The court, however, emphasized the importance of testing and acceptance terms stating, “parties to contracts for the sale of such software would be well advised to define ‘beta testing’ or ‘acceptance’ in the contract.” Id.
Conclusion
Significant amounts of time and money go into software development projects. It is important that the both the purchaser and the software company dedicate sufficient time and energy to the contract negotiation and drafting stage of the project. Expert legal guidance can be invaluable for the development of the RFP and response, statement of purpose, requirements, and acceptance criteria. Following the guidelines in this summary can help ensure that important questions about the contract are answered and, hopefully, help the parties avoid costly disputes.