© 2002, Deeth Williams Wall LLP. All Rights Reserved. By: Amy-Lynne Williams

It may surprise some people to learn that many companies will spend significant amounts of money and embark on mission critical software development projects without signing a detailed agreement clearly setting out what is to be developed, who owns what and what the respective duties and responsibilities of the parties are. Unfortunately, it happens quite frequently and although the projects sometimes turn out, all too often there are major misunderstandings about what was to be delivered, how much it would cost and how it would work.

Many development disasters could have been avoided if the parties had taken the time to discuss things ahead of time, before the enthusiasm for a new custom solution gets in the way of putting the details down on paper. It is sort of like hiring a contractor to build you a house without plans or an agreement setting out what you want. You may get a building with four walls, a roof, windows and doors, but it is unlikely that you will get what you had in mind. You would be even more surprised if the contractor ended up owning your house - something that can happen in a software development situation.

A good software development agreement should deal with certain basic points, including the following ten critical elements:

  1. Project Definition
    The parties need to clearly define what it is to be delivered. At a minimum, the agreement should include:
    • a definition of "deliverables" that describes all the elements the customer is expecting to receive - including code, documentation, reports, designs and other materials to be delivered by the developer;
    • specific milestones and checkpoints, at which the customer has the opportunity to determine whether and how to proceed to the next stage of the project;
    • where the software replaces existing software, specification of which party does the data conversion and how the conversion is to be tested; and
    • whether the developer is providing support and for how long.
  2. Project Management and Change Management
    Project management is the key to the success of any large project and each party should appoint a project manager. In particular:
    • the project managers should review deliverables, resolve disputes at first instance, meet regularly to keep the project on track and report to management at scheduled intervals;
    • the scope of authority of each project manager should be settled and communicated between the parties; and
    • some projects may justify the setting up of a steering committee to make decisions the project managers cannot.
    A process for approval of changes requested by either party should be included. Otherwise, there is a very real risk that a project will spiral out of control as the developer tries to satisfy the customer's wish list. No one will remember this when the deadline for completion passes without delivery of the final product. The change control process should insist that all changes be documented and should cover the definition, costing, approval and implementation of all changes.
  3. Specifications, Implementation and Acceptance
    The software should be developed in accordance with specified milestones and an implementation plan. The agreement should:
    • set out in detail each party's responsibilities - including for the delivery of specifications, code, approvals, training and documentation;
    • include thorough acceptance criteria and test procedures;
    • require the developer to back-up its work at least once every week or so and to store the back-up materials in a safe and secure off-site location during the development period, and
    • clearly set out who is ultimately responsible for the quality of the software.
  4. Prices and Payment
    Pricing can take many forms, including separate phase pricing, fixed pricing, payment on milestones, time and materials pricing or a combination of these. If pricing is to be done by phases, the agreement should set out what happens if the parties cannot agree on a price for the next phase or milestone, including who owns the work in progress. All elements of the price should be set out, including third party license fees, training, support and services. The agreement may also provide for a holdback of a percentage of the milestone payment to be withheld until final acceptance of the software.
  5. Ownership
    The agreement must set out which party is to own the deliverables and results of the development services. Developers will generally agree to assign the copyright in specific project deliverables but sometimes will not include rights in methodologies or know-how. Assignment language must be clear and all moral rights in the customer's software should be waived by all individuals involved in the development process.

    Use of preexisting third party works in the customer's software should first be approved by the customer. The nature of any preexisting work; restrictions or royalty terms applicable to the use of preexisting works; and the developer's authority to employ it in the customer's software should be specified.
  6. Warranties
    The developer should be asked to warrant that:
    • it is the sole author of all works employed in preparing any deliverables other than pre-existing works specifically listed;
    • it has the right to assign or grant the rights and licenses granted in the deliverables;
    • the deliverables will not infringe the intellectual or industrial property rights, or the contractual rights of any third party and no claim of infringement has been threatened or asserted;
    • the deliverables will be prepared in a workmanlike manner and with professional diligence and skill;
    • the deliverables will conform to the specifications, including any uptime and capacity requirements;
    • for a specified period after acceptance, the developer will correct any part of the software that does not meet the warranties;
    • the deliverables will not contain any viruses, hidden routines, expiry codes, disabling systems or any other functionality that is not fully and accurately set out in the specifications; and
    • it will perform changes to the software to ensure that it remains compatible with other relevant technology and programs used with the software, including without limitation, through the release of timely updates and upgrades and in some instances, it will perform changes needed to keep up with new legislation or rules that impact the customer.
  7. Liability and Infringement
    Most developers will require that their liability be limited, normally to the amounts paid or to be paid by the customer. The customer may require that the developer maintain insurance (including sometimes, errors and omissions insurance) and in many instances will only agree to a limit of liability which is a multiple of the amounts to be paid. Generally speaking:
    • the limitation of liability will not apply to claims for infringement and breaches of the confidentiality clauses - this is a negotiated item;
    • each party will want to provide that they are not liable for any special, indirect or consequential damages;
    • the customer may want an indemnity from any loss, claim or damages to data, persons or property;
    • the developer will be required to take responsibility for any infringement actions, which can range from a full indemnity against all claims and losses to a simple agreement to defend or settle claims made and pay any damages awarded against the customer. If the developer is a small company, this may not be comforting to the customer however, since it is unlikely that the developer will still be around if a major claim is made. Customers need to consider their own insurance coverage in that instance.
  8. Confidentiality
    agreement should specify what information is to be kept confidential, what use can be made of the information and what security measures need to be taken. Parties should avoid the temptation to have everything possible included in the definition of confidential information, since it can dilute the effect and the enforceability of the clause. The agreement may provide for the period of time during which the obligations of confidence will continue and normally the developer will be required to agree that the information will be kept confidential indefinitely.
  9. Remedies and Termination
    The agreement should include specific penalties for failure to meet project milestones. As an alternative, the customer may offer incentives if the developer meets or exceeds requirements.

    Some customers want the right to terminate work on the project without cause, although the customer will not want the developer to be able to terminate unless the customer defaults in the payment of any amounts due.

    If software fails an acceptance test, the developer should agree to correct any reported errors and submit the software for re-testing. If the software fails multiple tests, the customer should have the option of accepting the software, as is, at a reduced price, or rejecting the software completely. The developer should agree to remedy any other performance deficiencies at no charge to the customer and may also agree to financial penalties, for persistent failure to meet performance standards.

    Upon receipt of notice of termination, the agreement will normally provide that the developer:

    • advise the customer of the status of the completed to date and deliver all work in progress;
    • be paid for work accepted through to the date of termination; and
    • be required to return all material and information belonging to the customer.
  10. Dispute Resolution
    Any large project will generate differences of opinion and since the ultimate goal of the parties is a completed project and not termination or a series of lawsuits, the agreement should contain a process for a multi-stage dispute resolution procedure. The procedure should begin with resolution by the project managers with escalation to more senior management if it cannot be resolved. The final stage would normally involve a referral to an independent mediator or arbitrator and the parties need to decide whether this will be compulsory or whether resort to the courts will be allowed in some or all instances

CONCLUSION

With care taken at the start of a custom development relationship to define the obligations and rights of the parties in a clear agreement, many common project pitfalls can be avoided. The rush to get a project started should not obscure the need for a well drafted agreement to ensure that future disputes are minimized and that the customer can protect its investment in its software. The agreement will also assist the developer in its quest to get paid for its work and as always, the time taken to plan ahead and ensure that each party understands what the deal is, is time well spent.

Contact Amy-Lynne Williams for additional information on agreements and software development projects.

Disclaimer: This Newsletter is intended to provide readers with general information on legal developments in the areas of e-commerce, information technology and intellectual property. It is not intended to be a complete statement of the law, nor is it intended to provide legal advice. No person should act or rely upon the information contained in this newsletter without seeking legal advice.

E-TIPS is a registered trade-mark of Deeth Williams Wall LLP.

By Editors
Deeth Williams Wall December 24, 2002 December 24, 2002 July 8, 2015
Technology Contracting