BY MICHAEL J. SILVERMAN AND SANDRA A. JESKIE 1

KEY ELEMENTS OF AN E-COMMERCE INTEGRATION PROJECT CONTRACT BY MICHAEL J. SILVERMAN AND SANDRA A. JESKIE 1 According to Forrester Research, the top performing e-commerce integrator in Forrester s study scored only a C in Forrester s analysis of the 40 e-commerce integrators that generated at least $15 million in revenue per year from Internet-related projects. In ranking these companies, Forrester Research examined their strategy, marketing, design, technology and business practices. Significantly, within that top 40 group of e-commerce integrators, the average cost of a client s one-year relationship with the firm ranged from $2 million to $5 million. (Red Herring, February 13, 2001, pp. 104-110). Clearly, the business world is spending a great deal of money for this integration work, yet the industry is still in its infancy, and its practitioners are still learning their craft while struggling to keep up with changing technologies. How can a business mitigate the risk inherent in such difficult projects? Good contracts can help, particularly if the parties accept the view that the contracts are a tool to help both parties complete a project on time, on budget and with appropriate functionality. In fact, the most important elements of the contract are likely to be those describing how the project is to be managed and how the work is to be done. The following are a number of key contractual considerations that can help provide a strong, high-level guide to the developer and the client in making their relationship a productive one. Note that the principles set forth below apply whether a project is worth $10 million or $100 thousand. In either case, the failure or delay of an e-commerce integration project can mean that a company misses the lucrative holiday season or goes out of business. Project Requirements Establish the project requirements as early as possible in the relationship, and do not start principal work on the project until the requirements are clearly defined. Because clients are anxious to get their Web sites up and running, they often rush into starting work on a project before the parties really understand its scope and requirements. Developers should try to put the brakes on a project until the requirements are set, but with their clients demand for speed and their own need to push work out the door, developers often start work while still defining the project. The parties should also put the requirements into the contract, even if that means attaching a 100- page business or technical design document. Requirements documentation affects all the 1 Michael Silverman is a partner and Sandra Jeskie, who has 16 years of experience as a computer scientist, is an associate in the international law firm of Duane Morris, LLP. Both are members of the Firm s Information Technologies and Telecommunications Practice Group, which Mr. Silverman chairs. Ms. Jeskie is resident in the Firm s Philadelphia office, 215-979-1000, and Mr. Silverman is resident in the Chicago office, 312-499-4700. They can be reached at mjsilverman@duanemorris.com and jeskie@duanemorris.com. 2001 Michael J. Silverman/Sandra Jeskie, Duane Morris LLP

elements of the contract, from determining whether deliverables are delivered on time to determining which deliverables are acceptable under the contract. The requirements are the foundation of the relationship and the contract, so take the time to build a solid foundation. Often, the client will hire the developer to help prepare the requirements documentation as part of the project. If that is the case, the parties should make certain that the contract includes an appropriate mechanism for the client to review, understand, modify and, hopefully, accept the requirements documentation. Also, the client should have an opportunity to terminate the project with the developer if the developer cannot provide suitable requirements documentation or if the client believes the developer is not the right firm for the work that will be needed to turn the requirements into an operating system. The client will have to be truly committed to devoting appropriate, skilled, knowledgeable personnel to the project and to giving its employees the time and the freedom to do a good job as subject matter experts and project managers for the project. The need for client subject matter experts is greatest when the client and developer are working on the requirements for the project, but clients often do not devote the right employees to the project or give them the necessary time to spend with the developers. This can be a fatal mistake. If the appropriate people do not have sufficient time to work on the requirements, those requirements may be wrong or incomplete, resulting in a system that will not serve the client s business needs or a project that is burdened with a large number of scope changes resulting in delays and increased costs. It is a vicious cycle: if the parties do not spend appropriate time on the early stages of the project, they will pay later for their blunder. Thus, the parties may wish to include in the contract that certain client subject matter experts will be made available for the development of the requirements and will remain available throughout the life of the project, particularly during any testing or acceptance procedures. One of the key technical provisions in any implementation project is the requirement that the developer use the most up-to-date commercially available technology to develop the project. This provision can often save a completed project from becoming obsolete shortly after its delivery. Likewise, the contract should specifically detail the project s platform capability. Obviously, a provision which requires cross platform compatibility is the most desirable. Project Management and Schedules It is equally important to ensure that the project management is well defined and that the contract requires the application of disciplined project management practices. The project can often go astray as a result of seemingly minor slips in the schedule. A realistic milestone schedule can aid both the developer and the client in obtaining a realistic sense of things to come. For example, a developer who is anxious to obtain a client s business might verbally agree to a deadline for the final delivery of the project. The simple preparation of the milestone schedule, however, and the thought process involved in preparing that schedule, will sometimes crystallize some of the problems associated with the agreed-upon delivery date. Likewise, the preparation of a schedule can aid the client in getting a realistic sense of the details of the development process and 2

understanding the client s need to allocate its resources to the project. The client and developer will also benefit from the advance notice of defined project meetings that have been built into the schedule. Knowing that a meeting is scheduled in the upcoming week will often prevent a stream of phone calls from an anxious client determined to know the status of his or her project. Any productive meeting should have a predetermined agenda and is most useful shortly after the developer has provided one of its deliverables. Every milestone schedule should also include a critical path that identifies those events that absolutely must occur in order to meet the final delivery date. Even a minor slip in any event that has been deemed an element of the critical path can spell disaster for the project. Hence, resources must be fully allocated toward those critical path items. Another key aspect of project management is project staffing. The client and the developer should each identify a point person or project lead who is fully apprised of the issues and can appropriately and quickly respond to issues as they arise. The integration contract should also clearly identify members of the developer s team who will work on the client s project and include a commitment that those individuals will remain on the project and be available after completion for support services. Specificity of this nature in the integration contract will eliminate the pitch-and-switch that some clients have experienced. There have also been occasions in which members of the developer s staff have been lured away by lucrative job opportunities offered by the client who wishes to cut the middleman. This issue can be addressed by including a nonsolicitation clause in the integration contract. It might also be helpful to specify client personnel who will work on the project. Perhaps if specific client personnel are identified in the contract, the client s management team will be more apt to respect the commitment of those individuals to the project and less likely to take them away from it. Perhaps one of the biggest project management nightmares is the coordination and management of multiple vendors or multiple teams from the same vendor. For example, one team may be developing the look and feel of the Web site (with eye-catching graphics, great text and lots of animation), while another team is working on the integration of accounting, order management, credit card processing, and other necessary e-commerce functions. All the teams should understand their roles in the project, when their deliverables are required, and how those deliverables are expected to integrate with all the other deliverables. A good project plan and contract will include details of the responsibilities of all the various providers or teams involved in the project and will provide structured methodologies for managing the relationships among the teams. Change Control Inevitably, the client will want to make some changes to the project requirements. A carefully documented procedure for all changes will make this process more manageable. Each proposed change must be accompanied by the developer s analysis of costs associated with the change and resulting effects to the milestone schedule. The client must sign off on the developer s analysis before the changes can be implemented. 3

Deliverables and Acceptance Testing A series of interim deliverables are also necessary in any significant project. It is no longer sufficient to wait until the end of the project to deliver the client a final product. Doing so will almost always result in an unsatisfied client whose expectations were vastly different than those of the developer. Although developers may disagree, the best way to ensure a client is happy with the end result is to establish a schedule that provides the client with numerous interim deliverables on which the client must sign off after the client s detailed review. The client will feel encouraged by the progress on the project and the process of examining and approving interim deliverables can help identify, earlier rather than later, gaps between the client s expectations and the developer s system. The contract should establish clearly defined objectives for each deliverable. Each deliverable must be tested by the developer prior to delivery and by the client after delivery. For the benefit of both parties, it is important to clearly establish acceptance procedures for each deliverable and a method for problem resolution that must be specifically addressed in the integration contract and included as part of the milestone schedule. Also, the client may want the developer to certify that each deliverable was prepared in accordance with the developer s or the project s standards and methodology. Payments should be linked to acceptance of deliverables, and, if possible, there should be a holdback deducted from each payment until final acceptance of the entire system. Performance Criteria A minimum performance criteria should be established. Ideally, the parties should identify the specific performance criteria for a specified volume of expected users and the contract should detail the specifics. For example, in a Web site hosting agreement, the contract should, at a minimum, detail the speed and bandwidth of the Internet connection, the amount of expected uptime, server response times and capacity, scheduled maintenance periods, backup frequency, as well as a disaster recovery plan. Obviously, the performance criteria will vary significantly depending on the type of project, but the importance of these details should not be underestimated. Ownership and Rights The integration contract must address the important issues of ownership and rights of both the developer and the client in the project content and the source code or software. For example, questions such as who owns newly created copyrightable expressions must be addressed upfront. The property rights concerned can include copyrights in text, sound recordings and visual arts, as well as rights of publicity and privacy in photographs or other representations of individual personal characteristics, if applicable. The client should ensure that its rights in the project are protected by obtaining appropriate licenses from the developer for software or content created by the developer. Further, developers 4

often incorporate third party software in their work, and if so, they should obtain licenses for the client for that software. Alternatively, the system can be developed as a work for hire under U.S. copyright law. Normally, the author or creator of a work owns the copyright to the work; however, if the work (a system) is created as a work for hire, the person for whom the work is being made (the client) owns the copyright. It is, however, important to define the scope of the work made for hire. The work for hire agreement should specify which deliverables are works for hire and which are not. All rights, title, and interest in and to the copyright of other works created or developed under the work for hire agreement should be assigned to the client. The developer will want to reserve its rights in its own proprietary software and tools it used to develop the project, but the client should still get a license to use the software. Such software might include software created by the developer for use on all its projects, like an electronic shopping cart. Finally, the contract should identify which party is responsible for securing or providing the proprietary rights identified in the project. The party responsible for obtaining such rights should indemnify the other against any failure to obtain the requisite rights. One of the more interesting intellectual property issues to consider is which party owns jointly developed intellectual property. Where client and developer teams work closely on a project, they may jointly develop a new technology or methodology, such as a method of ordering on the Web similar to Amazon.com s hotly disputed one click process. Who should own the rights to this new technology or methodology? The easiest answer is that both parties should own and/or have the right to use the new technology or methodology; however, this issue, if it is addressed at all, can be hotly contested. Confidentiality At the project s inception and throughout its development, each party will become privy to certain confidential information of the other: business practices, customer lists, marketing material and similar information. Hence, it is important to address confidentiality at the first meeting between the developer and client, but it clearly must also be addressed in the integration contract. Each party should be subject to a nondisclosure requirement. All documents containing confidential information should be returned at the conclusion of the project, and the integration contract should provide a remedy for breach of the confidentiality provision. Dispute Resolution Unfortunately, disputes arise and identification of a dispute resolution procedure is best addressed in the integration contract. The contract should include a provision that the parties will agree to meet and confer about any disputed issues. In the event that the parties cannot resolve the issue, the contract should include a choice of law provision and should identify the appropriate forum for resolving the dispute. Often, parties agree to bring disputed issues to binding arbitration governed by the American Arbitration Association or another alternate dispute resolution organization. Judgment on the arbitration award can be entered by any court 5

of competent jurisdiction. To avoid disputes that result in all-out war, the parties might include in the contract an internal dispute resolution process that progressively sends the dispute to higher levels of authority within both parties. For example, if the project team cannot resolve a dispute within a certain timeframe, then the dispute can be escalated to a project steering committee. If the steering committee cannot resolve the matter, it can be escalated to high-level officers of both parties for them to attempt to make peace. The parties may identify in the contract a third party expert (such as a knowledgeable business person, lawyer or consultant) who can resolve disputes for the parties. Only if these processes fail would the parties resort to external dispute resolution by arbitrators or the courts. Conclusion There are a myriad of additional important issues which must be addressed in an e-commerce integration contract. This article is intended only to provide a guideline on some of the significant issues, which in our experience, have become critical in the relationship between the developer and client. Given that the industry is still in its early stages and that the technologies involved change so quickly, e-commerce integration projects can be quite risky. Good contracts can help manage and mitigate the risk, and the advice of counsel familiar with such projects can help smooth the path of a successful e-commerce integration project. CHI\65589.3 6