How to contract for a successful e-commerce development project: beating the odds

EXECUTIVE SUMMARY

The success of e-commerce/technology development projects increases immeasurably by applying the discipline of project management. Project management requires that the three critical resources–people, time, and money–all be scheduled and allocated in advance, that progress is monitored regularly, and that any slippage in time, cost, or quality is recognized early and resolved by the parties immediately. The lawyer advising clients involved in these deals must draft the contract so that good project management principles are contractually required. This Article discusses what project management is, why it is essential to project success, and what the lawyer must do to make good project management a contractual requirement.

PROJECT MANAGEMENT IS NOT A LUXURY FOR E-COMMERCE PROJECTS

E-COMMERCE PROJECTS ARE COMPLEX INFORMATION TECHNOLOGY (IT) PROJECTS

The scope of e-commerce infrastructure projects is growing. (1) What were once brochure style Web sites are now true retail sites where actual inventory is offered, products are purchased, payments are made, and shipment is arranged. Web sites that offered essentially online catalog shopping have been superseded with sophisticated portals providing greater shopping convenience for consumers and better data management for vendors. These sites can track customers’ activities to provide value added services. Many companies are moving towards fully integrating the selling with all other functionality including order processing, client relationship management, accounting, marketing, and inventory management. (2)

Having seen the potential for Web-based e-commerce, many companies are also engaged in using the Web to allow their own employees, consultants, vendors, and business partners to share data and to perform sophisticated transactions in real time.

MOST COMPLEX IT PROJECTS FAIL

To build the e-business infrastructure, many different systems must be integrated

According to what has been referred to as the “landmark” (4) 1994 white paper published by the Standish Group (a well-known consulting firm), 31.1% of IT application development projects will be canceled before they ever get completed. (5) The overall success rate (completed on-time and on-budget) was only 16.2%. (6) Further, cost overruns are rampant, with 52.7% of projects costing 189% of the original cost estimate. (7)

The Standish report observed that the “successful projects” are often “no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions.” (8)

While the numbers have improved some, by 1998, Standish reports that 26% of the projects were successful
If building construction had the same ratio of cancellations as software,
more than half the office buildings in the world larger than 30 stories
tall would be abandoned before completion. The average height of buildings
in New York City would be only three stories, and there would be no
skyscrapers. (11)

The more difficult or larger scale the technology implementation, the greater the risk of failure. (12) E-commerce projects are quite large, often starting at $250K, and most costing millions of dollars. Problems along the way are to be expected. Without the project management processes being contractually imposed on the parties, no one will recognize a problem until it is too late. There is no mechanism to resolve it. Schedules and budgets are not adhered to, expectations are not met, and the surprises can be of such a magnitude that the project will fail. The results are costly and can jeopardize companies and careers. Examples are legion and include:

* A brief planned outage for a system upgrade at e-Bay went wrong causing a twenty-two-hour outage and a loss of $6 billion from the company’s market capitalization. (13)

* Victoria’s Secret, the retailer of lingerie and swimsuits, used an advertisement during the telecast of the Super Bowl to promote a simultaneous Webcast fashion show. (14) “More than 1 million people attempted to log on to the show, swamping the site, slowing response time, and leaving many frustrated visitors viewing only error messages.” (15)

* The Greyhound Lines, Inc. “Trips” reservation and bus-dispatch system which cost $6 million in the early 1990s failed miserably and crashed when Greyhound offered sale prices. (16) Agents had to write tickets by hand while customers waited in line. (17) The losses amounted to $61.4 million in one quarter alone, and the chief executive officer and chief financial officer resigned. (18) “Greyhound never regained its status as a transport powerhouse.” (19)

* The Hershey Foods Corp. compressed the roll-out of a new $112 million ERP system by several months in order to meet the Halloween and Christmas seasons. (20) Problems including inaccurate inventory data resulted in shipment delays and incomplete orders. Sales were down $150.5 million compared to the same quarter over the previous year. (21)

* Oxford Health Plans Inc.’s migration to a new set of applications resulted in massive payment delays and errors, overestimates of income, and underestimates of costs. (22) The company reported its first loss of $78 million and overestimated revenues by $173.5 million in one year and $218.2 million the next and was fined by the state of New York for violating insurance laws. (23)

* The State of New Jersey entered into a $500 million contract with Parsons Infrastructure & Technology Group to privatize over thirty auto inspection stations, revamp the IT infrastructure and implement new emissions testing equipment that uses a treadmill to gauge emissions while in motion. “Immediately equipment failures and understaffing created four-hour lines at inspection stations. Then, during a January cold snap, Parsons was forced to close a number of stations because the emissions equipment froze up in near-zero temperatures.” (24)

* Problems implementing a $234 million dollar automated baggage handling system delayed the opening of the new Denver airport from March 1994 until February 1995. (25) That delay reportedly cost the city of Denver $1 million per day in operations costs and interest on bond issues totaling more than the actual price of the project itself. (26)

The impact of a failed project is greater in harder economic times. Many companies are forced to tighten their belts and “focus[] on IT projects that they’re confident will provide tangible business benefits.” (27) “During 2002, businesses and their top executives will not tolerate failure. They will expect service providers to deliver ROI within required time frames and with expected functions….” (28)

The success rates on IT projects for different industries vary. The retail industry had the highest success rate, almost three times that of government projects. (29) The “low-margin retail industry cannot tolerate waste. The government, on the other hand, faces no such challenge.” (30) In tougher economic times, it would be expected that all industries would approximate the retail industry as their margins decrease.

PROJECT MANAGEMENT HELPS MAKE E-COMMERCE PROJECTS SUCCEED

If the project is to have any chance of success, the project must be properly managed. The projects fail “not for lack of money or technology

Five years later when the Standish Group did a follow-up study they found that the success rate had increased by 10% from 16% to 26% and this improvement was attributed entirely to project management. (33) “Better project management and better quality control are the most important differences between success and failure in the software world.” (34)

A study by PriceWaterhouseCooper, LLP of twenty-five years of litigation arising from IT systems failures, (35) identifies some of the basic tenets of good project management as lacking in litigated IT cases. They include:

* Agree ahead of time to expectations, promises and contingencies

* Include performance and compatibility requirements, anticipated life span and acceptable levels of defects in systems specifications, as well as required functionality

* Clearly define key terms, conditions and activities

* Review documents up and down the chain of command in both organizations to make sure all relevant personnel understand what’s promised and what’s expected

* Implement small, comprehensible and workable systems at first before expanding into the desired large systems

* Get expert legal and IT guidance before signing anything

* Act quickly when problems arise

* Work with vendor to achieve the desired goal. (36)

The PriceWaterhouseCooper’s report concludes that “[j]udicious thought, consultation, and agreement on detailed terms, especially before entering into a legal agreement, will go a long ways to avoiding [identified] patterns, reducing the risk of or need for a lawsuit.” (37) The report acknowledges that these are commonsense suggestions but asks why commonsense is set aside or ignored. (38)

PROJECT MANAGEMENT MUST BE COMPELLED

The business people may not fully realize that unless the contract requires the parties to abide by these principles, compliance will be at will and not legally enforceable. To be legally enforceable, the contract must spell out in detail how the project will be managed.

Good project management fosters on time and on budget delivery of goods and services. Deliverables are provided which are consistent with expectations. Detailed descriptions of deliverables, processes, time schedules, and budgets are prepared and agreed to and adherence is mandated. The contract must set forth in detail each party’s rights and responsibilities including what will be delivered and when, how much will be paid and when, how the deliverables will be determined to be accepted and how any deficiencies will be resolved, and how changes to the deliverables, budget and schedule will be suggested, approved and implemented.

Any deviance from the schedule, budget or any unacceptable deliverable is identified early. Adjustments are made and agreed to as soon as they first become evident. Project management process imposes control. Surprises are avoided and expectations are met. The chance of failure is minimized.

Many contracts only have a cursory description of the product and services to be provided, a formula (based solely on the number of hours and professional fees) for calculation of costs, and a single end date when the products and any related services are to be delivered. This may work, but only in the simplest circumstances where there are no problems in developing, delivering, and implementing the technology. Custom e-commerce systems are not simple “off-the-shelf” systems.

The lawyer’s involvement comes when two or more separate parties embark upon an e-commerce infrastructure development effort. At that point, the parties recognize the need for a written agreement memorializing their respective rights and responsibilities. When discussing the contract, too often, the parties are focused on the “what” and not the “how.” It will likely fall to the lawyer to insist that the agreement does adequately address and define both the what and the equally important “how.” That “how” is the essence of project management and without it defined in the agreement, the chances for project failure increase dramatically. By making sure the parties understand the details of how the project will be performed and including those details in the agreement, the lawyer can actually increase the likelihood of project success.

The reasons for requiring the parties to develop IT projects using good project management principles are obvious and commonsense but, as the PricewaterhouseCoopers study asks, why is commonsense set aside or ignored? (39)

WHY PROJECT MANAGEMENT PRINCIPLES ARE OFTEN OMITTED IN CONTRACTS

There are several reasons why contracts often fail to impose upon the parties specific obligations to abide by good project management principles. None of them are sufficient.

DRAFTERS DO NOT APPRECIATE THE IMPORTANCE

The people drafting and negotiating contracts (i.e., lawyers), as a rule are not trained in project management and do not understand how to formally manage a project. In fact, most lawyers charge for their work on an hourly basis and only relatively recently have been asked by their clients to provide the barest of project management metrics, budget, and schedule estimates. (40) Managing a complicated, multi-disciplinary project and understanding its intricacies and how to control a project involving numerous interdependent subtasks performed by different teams of people is a skill set not taught in law school. Lawyers not exposed to project management and who do not understand both how it operates and why it is important, will not understand how to write a contract which embodies project management of any kind. (41)

FEAR OF COMMITTING TO SPECIFICS

A second reason is that the parties, particularly the ones developing the technology, may feel that committing to specifics, as will be required in a proper project management set of “specifications,” will ultimately work to their detriment. Often parties feel that the less said the better for the party delivering the technology. This may be true to a degree, but to the extent that there has been no meeting of the minds with regard to each party’s rights and responsibilities there will likely be a dispute. (42)

The failure to include detailed specifications in the agreement can hurt the technology developer. If project management protocols are embodied in the agreement and the budget, deliverables, and payment schedule are set forth in the agreement, the technology provider will be protected against unrealistic client expectations and will have ready defenses in the event of a dispute.

DETAILED PROJECT SPECIFICS DO NOT EXIST

A third excuse is that the parties perceive that they must know every minute detail of what product and services must be provided. Because those details will be developed as part of the project, the feeling is that there is not yet the requisite specifics to bind the parties at the time the contract is written. Wrong. Rather than enter into an agreement which is vague and unclear, (43) the contract should be written so that it binds the parties to a process to develop, approve, memorialize, and modify those specifics and requisite details. If the parties have not discussed and cannot agree on what the process will be for actually producing technical specifications, they are not ready to enter into a contract that will require that they jointly work together to produce the end product.

One way that this third reason is articulated is that the parties feel that the “project” is entirely a “collaborative effort” and there are no defined deliverables. There may be a budget and a schedule incorporated into the proposed agreement, but they are so open-ended as to be useless in any subsequent dispute resolution activity.

Even if the parties are going to work “together,” certain responsibilities need to fall to each one. On some level, all parties must concede that they will agree to do certain things. A budget and a schedule should also be discussed and set, at least preliminarily. The contract should define how the parties will work together, what parties have what responsibilities to create the plan for the project, how objections will be raised, how changes will be made, how agreement will be reached, and how new responsibilities will be allocated as they arise. If this cannot be done in advance, it will not likely be done successfully as the project goes forward, especially if the parties have no agreement defining how they will proceed.

CONCERNS ABOUT COST

A fourth unfounded excuse is cost. The fear is that the additional obligations imposed by making project management a contractual requirement will increase costs significantly. These costs include adding structure and specifics to the contract plus preparing and agreeing to detailed specifications. The glib vendor response to this is, “What, you think we weren’t going to manage the project well?” If the project was not going to be managed with any timetable, defined deliverables or budget, it would not likely have been successful.

The additional costs to make project management a contractual requirement are the marginal or incremental costs of writing the contract so that it imposes detailed requirements and administering the contract according to those requirements. The detailed requirements must be developed as part of the project, regardless of whether or not they are made a contractual requirement. The costs incurred to implement project management protocols should be weighted against the cost of project failure. (44) The cost of project failure can be much greater than the entire cost of the project because there are other costs to factor in, such as the opportunity cost and the cost of dispute resolution.

Parties executing a project with good project management principles prepare, track and refine budgets, schedules, design specifications, code, acceptance test criteria and other documents detailing what will be done, how and when. Because these materials are prepared as part of the development effort, they need not be specially created. The requirement and process to develop and modify those items can be included in the agreement.

Thus, the only additional costs to require the parties to execute the contract consistent with the principles of good project management should be the lawyer’s time spent making sure that the contract embodies and reflects how the parties plan to run the project. This may lengthen the negotiation because a much greater degree of detail is required. This is a small price to pay, however, to obtain a significantly greater likelihood of success.

PROJECT MANAGEMENT PRINCIPLES THAT SHOULD BE INCLUDED IN THE E-COMMERCE INFRASTRUCTURE DEVELOPMENT CONTRACT

To understand how project management is incorporated into technology development agreements, consider a building construction project. “Building software is analogous to building a house: It starts with determining what the customer can afford (budget) and wants (requirements).” (45) It then proceeds to design layout (functional specifications), then to architectural drawings (detailed specifications), and then to construction (design and implementation). (46) “After the building is done, it is inspected (quality assurance [or acceptance testing]) and any problems (bugs) are fixed.” (47)

DETERMINING AND DEFINING THE PROJECT SCOPE

The most important first step is making sure the client has a clear vision of what the end result of the project should achieve. Rather than jumping immediately into the project and defining its bells and whistles, the parties need to think strategically to define the measurable results the project should achieve. (48) If this is not done in the beginning, the project is likely destined for problems and even failure.

Tough questions must be asked and answered such as: “How will you measure success at the end of this project? What do you really want to buy for all this money…?” (49) The answers to these questions will eliminate conflicting expectations.

How successful results are defined will depend on the project. It should not, however, be expressed in lofty unquantifiable terms like “better customer service” or “offer more products to the consumer.” Rather, project success should be defined as a “linked chain of measured achievements … [created] by starting at the end of the project … [t]he last achievement is the sponsor’s definition of success.” (50)

For example, “providing good customer services” may be defined for an e-commerce site as having online user’s average time to download the site less than 5.0 seconds. People may argue about that amount of time–the point is to force that discussion and define good customer service before the project gets started. The goal is to reach agreement on what the client really needs before the costs of design and coding are incurred.

In the customer service example, for an e-commerce site, a 5.0 second download time is meaningless if large numbers of users cannot even get on the site. The percent of availability must also be specified. For its second Webcast, Victoria’s Secret spent $9 million to significantly increase its capacity and used a dedicated hosting rather than a shared hosting facility. (51) The average time to access the site during the Webcast was 5.0 seconds with 97.9% availability. (52)

In evaluating the client’s statement of scope, the lawyer should look for signs of scope problems, such as “unclear purpose,” the defined scope “doesn’t adequately address the objectives of the project, or its expected benefits,” “gaps in definitions,” “insufficient detail,” “hidden assumptions,” “undocumented interfaces,” “items don’t fit” or make sense, “wrong participants/approvers,” participants on the verge of asking questions but failing to verbalize them, and “unresolved issues.” (53) The lawyer seeking to help the client assure the success of the project should critically evaluate the scope to help ensure the project’s success and to negotiate an agreement which will increase the chances of success. If the scope is not defined correctly, the project will have problems which the contract cannot likely cure.

By forcing the issue to fully develop the scope so that the client is forced to articulate what it really needs before the project coding commences, the project has a much greater chance of success.

MANAGE EXPECTED CHANGES WITH A CHANGE ORDER PROCEDURE

There will always be changes to the scope of the project. (54) Systems development and design by its nature is an iterative process with each pass adding more and more detail. As the work progresses it goes from concept to concrete and the need for change and modification will naturally arise. Also, e-commerce development is not done in a vacuum. It is subject to lightning-fast changes in business and technology. Generally, the longer the project goes on, the more changes there will be. (55) The contract must have a defined procedure that will allow for proposing changes to the scope, documenting the impact of those changes on the project budget, schedule and personnel, and accepting or modifying the change in scope.

While each project is different, the parties need to establish a procedure for proposing, modifying, and accepting changes in the project. In order to effectively administer the agreement, any change in scope of the project which will impact a deliverable, the delivery date or the amount of resources (money, people, and materials) should be memorialized in a written change order. The actual changes and the impact they will have on other aspects of the project should be included in the change order signed by both parties. This is so that a clear record is made and each party cannot later claim that they did not agree to a specific change or a particular aspect of that change.

PROJECT PLAN INCLUDING BUDGET, SCHEDULE, DETAILED SPECIFICATIONS, AND DELIVERABLES

Once the scope of the project has been determined, a project plan needs to be developed. The project plan includes a budget, a schedule, and a list of deliverables including detailed specifications. The more detailed these are the more closely the project will be managed. The budget, schedule, and deliverables are all inter-related. The project plan spells out what each of the deliverables are, when they will be provided, and how much each will cost. The project plan typically breaks down the work to create all deliverables into numerous subtasks and then orders those subtasks in a critical task order setting forth dependent and independent tasks.

As many of the details available at the time of the agreement as possible should be included in the project plan and the project plan should be referenced in the agreement and included as defining some of the specific contractual obligations of the parties. Additional terms can be developed and agreed upon through an iterative process set forth in the agreement and as discussed below. The discipline of developing a project plan will likely uncover areas where the parties are not in agreement on how the project will be executed and will force these items to be resolved before they present a serious problem.

PROCESS FOR DEFINITION AND AGREEMENT ON DETAILED SPECIFICATIONS

Because all the detailed specifications of what will be created are not usually known at the time the parties enter into the contract, the contract must set forth a process for developing and approving those specific details and having the parties agree to them. (56)

The process should establish the means for exchanging information between the parties and assembling information from others. The process should set forth which party will be responsible for certain elements of the project and what and when items to be developed are due. If one party’s responsibilities are dependent on input from the other, the process should set forth a means for evaluating the adequacy of the input and time frames for providing that information or work product.

Further, there should be certain reports, summaries or written proposals which are exchanged wherein what is agreed to is memorialized. These tangibles, along with what is ultimately produced, are considered deliverables just as much as the code. Each should be spelled out in detail in the contract.

The timetables for providing the detailed specifications and completing processes should also be spelled out in the agreement. Where possible, the actual development work should not commence until after the project plan is completed.

PROJECT PLAN DELIVERABLES

For e-commerce transactions, for example, there are two essential preliminary deliverables: the functional specifications and the technical specifications, together the detailed specifications.

The functional specifications are a general description of how one sees or operates the system. They usually include a system overview, a high-level description of the system functionality, a description of the architecture, description of interfaces with other systems, and a description of the “look and feel” of the system.

The technical specifications detail how the system will be implemented by the coders. The technical specifics include descriptions of what hardware and software will be used to run the system, how the system will be implemented, detailed technical description of the functionality, how the look and feel of the system will be implemented, and what database, interfaces, and reports will look like.

As discussed below, the detailed specifications should also include a general description of the acceptance tests and the data to be used. This will allow for the development of detailed, fair, and objective determination of success (or failure) of deliverables. Other technical specifics include the details of documentation, training, and support that will be provided.

The outgrowth of the detailed specifications will be a more detailed list of deliverables including design documents, flowcharts, and even coding and documentation, as well as a schedule of delivery dates and payments.

OBJECTIVE ACCEPTANCE AND PERFORMANCE TESTING AND APPROVAL OF DELIVERABLES

Although the detailed specifications will define the acceptance test and data, the agreement must include the procedures the parties must use for turning over materials for testing, conducting tests, advising of test results, retesting procedures, remedies and penalties for failed tests, and exit/termination methods if acceptance does not occur.

The agreement should set forth a procedure for developing and agreeing upon objective tests for each separate deliverable and for the deliverables as a whole when development is complete. Those tests should define the functionality, navigability, specific data to be handled and the outcomes, as well as how the system as a whole should operate and interact. Making the tests objective and defining them in advance reduces the likelihood of a dispute regarding whether a test is successful. The party developing the technology has a clear target which cannot be moved at the last minute without mutual agreement of the parties.

Such testing should be done for portions of deliverables as they are produced. A deliverable, however, may work fine in a stand-alone mode, but may not work as designed with the other deliverables. Therefore, a final comprehensive test to make sure all the separate components work together correctly is also required. It is only when the entire development effort is complete that all functionality and the inter-relatedness of the separate (previously tested) deliverables can be tested in total.

BUDGET AND PAYMENT TIED TO DELIVERABLES

Money is an effective motivator. Payments should be made as deliverables are provided and accepted. This serves to foster good project management for several reasons.

First, if each payment is tied to a specific deliverable, the payment is not automatic. The party receiving the payment has to provide something in order to get paid. If it is not provided or what is provided is not acceptable, the agreement should set forth how payment can be withheld. The withheld payment is the incentive to fix the problem quickly.

Second, by tying payment to a deliverable, the party making the payment receives something of value in return for the payment. If there were to be a problem later and the project ends abruptly, the party making payment should have its hands on something of value which approximates what has been paid. Without tying payments to deliverables, the party could be left with nothing.

A particularly important example of when tying payment to deliverables is crucial is when the project involves an extensive design effort before the coding begins. The agreement must specify that compensation for the design effort be tied to delivering that portion of the project. Other points in the project where there is similar valuable work product completed should be used to develop the payment and delivery schedule.

Third, tying payments to deliverables prevents uncontrolled cost overruns. If each payment is tied to a specific deliverable or set of deliverables, surprise cost overruns are unlikely As each deliverable is produced, it is paid for at an agreed upon amount.

Fourth, tying payments to deliverables will keep the project on schedule and allow the parties to monitor any delay. If a deliverable is not provided, no payment is made. The party to be paid will be motivated to provide deliverables on time so that it is paid on time. By setting forth many small deadlines, delays will be apparent early on, especially if payment is withheld. While it may seem like tying payment to deliverables benefits only the party acquiring the technology, this is not true. The terms should be crafted so that the party doing the development is compensated in a way that correlates closely with the effort expended. Further, if payment is conditioned upon acceptance of deliverables, this should prevent revisiting whether the deliverables produced are acceptable. If the acceptance tests are defined objectively, there should not be any quibbling about whether the deliverables are built as promised. If the terms are fairly written, tying the payments to deliverables should protect the party providing the technology as much as the party acquiring the technology.

If the party being paid complains about cash flow issues, the deliverables can be defined so that the payment stream can be tailored to the respective parties’ needs. In fact, a stream of deliverables spread evenly throughout the project will allow the parties to make even payments and learn about the caliber of work early on. If the bulk of the deliverables are not due until the tail end of the project, problems may not be apparent until it is too late to correct them. If there is a problem, it is better if it is apparent sooner and the parties can either resolve it or terminate the agreement.

OWNERSHIP OF INTELLECTUAL PROPERTY RIGHTS

The agreement must specify what rights each party has to each deliverable. For example, if the party paying for that design effort wants the option of hiring a new developer once design is complete, the agreement must assign or exclusively license to the buyer the necessary intellectual property rights to the design. (57) Such an exclusive license or assignment of intellectual property rights may cost the buyer more than a mere non-exclusive license to use because the developer could not re-use the assigned design for its other clients. Thus, if the buyer decides to only non-exclusively license the design, and let the developer re-use it for others, the buyer might still want to prohibit the developer from using the design with the buyer’s competitors. The agreement must define those agreed-upon prices and the limitations on the use of those design documents by the developer.

If the parties have had these discussions about intellectual property ownership and use in advance and provided for it in the agreement and in the pricing, development and the post-development relationships will be more stable and the parties can avoid surprises regarding intellectual property rights that result in litigation.

PENALTIES AND BONUSES

The agreement should include penalties for failure to perform and can even include bonuses to encourage exceptional performance. The penalties and bonuses are usually financial and should be crafted so that they are not unnecessarily punitive or excessive, but will motivate each party to perform in full, on time and on budget, and keep the other party informed of any problems. The penalties and bonuses should be tailored to address the specific situation or breach which gave rise to the penalty or bonus. The penalties and bonuses can be static or escalate depending on objective criteria. At a minimum they should be used to encourage the parties to work closely with each other.

Often in first drafts of agreements prepared by technology acquirers, there is language which poses economically punishing penalties for relatively minor infractions. For example, a missed delivery date results in no payment for that deliverable until the project is complete. If the agreement is not re-worded to allow for a catch-up payment when the deliverable is actually provided, the developer’s cash flow will be seriously impacted. (58) If it is a small shop, that may impact the developer’s viability and hamper his ability to keep top talent.

PROCEDURE FOR IMPLEMENTATION OF COMPLETED PRODUCT

The parties must define in the agreement how the work product, once completed, will be turned over and implemented. Often, technology may work fine in a test mode, but actually running it in a production mode and interfacing it with the entire production environment can be tricky. The agreement should set forth the procedure for handling this, as well as the respective parties’ responsibilities and schedule for accomplishing this.

This must be included in the agreement so that there will not be a dispute later on. If the developed technology never gets up and running, the entire exercise is pointless and the technology developed is worthless. There will be litigation. It makes sense to avoid later disputes by defining these responsibilities in advance.

TERMINATION PROVISIONS FOR ALL OCCASIONS

All too often, the parties associate termination with failure and do not want to consider how it will work should it happen. Defining how the parties will walk away from the project is as important as defining how they will go forward with it. While almost all agreements have a termination provision, most are written without really considering the practical effects of a termination and, if ever actually invoked, will create more problems than they will resolve. The parties should, therefore, consider in detail and resolve what will happen under all the different possibilities where one party or both decide that they no longer want to continue.

There are several possible termination scenarios and the agreement must provide for each of them. If it does not, the parties will be forced to seek outside intervention–litigation or arbitration–to resolve any uncertainties.

Generally, the agreement can be terminated for cause or not for cause. Usually the party paying for the technology can terminate either for a given reason (for cause) or for no reason. The termination provisions, however, should reflect whether the termination is arbitrary (for no cause) or not (for cause). Usually the party doing the technology development is not allowed to walk away for no reason and can only terminate for cause.

If the termination is for no reason, the penalty or buy-out is usually more costly to the party terminating. This is to discourage arbitrary conduct and for equitable purposes to compensate the party terminated for no cause. If the termination is for cause, the agreement should be written to reflect that a party has failed to perform its obligations and the penalties should fall to the party in breach.

The termination provisions should also specify who walks away with what. It is entirely possible that there will be a fair amount of work in progress, certain deliverables will be complete and others will be partially complete. The agreement should set forth a formula to calculate what payments, if any, are due. It should also set forth which party owns the intellectual property in the items created, how those ownership or licensing fights will operate, who can continue with the development effort and for what purposes, the physical format (e.g., electronic, paper) of the work product to be delivered, and any obligations to assist in transferring the work product and ownership rights to that work product. (59)

In order to ensure that work product of value will be available if the parties become unwilling or unable to work together, it may be appropriate to require that it be deposited with a third-party escrow agent at defined intervals. Generally, the deliverable is not deposited into escrow until it is complete and sometimes not until the entire project is complete. If the party, however, wants some assurance that what has been paid for is available, there must be an escrow requirement in the agreement which requires deposit of materials at specific junctures and the party potentially needing the material must regularly verify that the agreed-upon deposits are actually made so they will be available if need be.

In fact, a well-written termination provision can serve as a good project management tool by acting as an incentive to keep the parties working together. If the party knows the penalty for walking away from the project mid-stream because it is clearly set forth in the agreement, that party can make an informed decision. The price of walking away reflects the economic impact on each party. The parties, if they do decide to terminate, can move on without wasting needless time and resources feuding over fees owed and ownership of work product.

DISPUTE RESOLUTION PROCEDURE THAT FOSTERS COLLABORATION WHERE POSSIBLE

The dispute resolution should be written into the agreement so that it will effectively deal with two different types of disputes: one where the parties can solve their differences and go forward and one where the parties cannot. Too often the dispute resolution the contract includes is written to address only those situations where the parties cannot resolve their differences. If not written to provide for both types of situations, the dispute resolution procedure mandated by the contract will have the effect of turning a dispute which should be resolved quickly into one which causes the whole project to unravel.

A dispute resolution procedure for fixable disputes should require a meeting of top officers or executives of all involved parties as soon as possible. They should be required to make a good faith effort to resolve the dispute. If that is unsuccessful, an independent mediator should be agreed upon as soon as possible and there should be mediation. Mediation should be an expedited and relatively informal process where the parties meet with a third party to try to facilitate an amicable resolution. That third-party mediator should have special experience and understanding of the type of work involved so that he or she stands a better chance of helping the parties to resolve the matter.

This fast-track face-to-face approach is designed to foster resolution of disputes quickly before the parties have become entrenched in their positions. Elaborate written position statements or meetings where there is a witch-hunting mentality are to be avoided at this stage.

If the parties cannot resolve their dispute through meetings and mediation, the problem is probably too severe for the project to continue and there will be litigation. The dispute resolution procedure of the contract, however, can provide for a surrogate for litigation that is either binding or nonbinding arbitration. The advantage to arbitration is that the parties can define in the contract how the arbitration procedure will work. If this method is carefully defined it can be less onerous than lengthy, costly litigation.

CONCLUSION

Most complex IT projects fail and e-commerce is no exception. Project management, therefore, is essential for e-commerce development projects.

Such a contract maintains better control over the work and ensures the project is completed on time, on budget, and without any major surprises.

While there are many aforementioned examples of projects failing because of poorly written agreements, a final instructive example is the auditor’s report on the $500 million privatization of New Jersey’s automobile inspection system which left New Jersey motorists waiting in lines for more than four hours to get mandatory car inspections. With the benefit of hindsight, that audit report summarized how to incorporate project management principles in high-technology contracts to avoid failure. The contract must have “specific performance standards and related testing procedures and protocols, and … [include] interim performance and payment milestones, backed by meaningful retainages and liquidated damages, as well as incentives, such as early completion bonuses.” (60)

There are additional costs when obligating the parties to follow good project management practices. It will require the lawyers and the business people to spend the time acquainting each other with what they are trying to accomplish and how. The contract will have to be written to include terms obligating the parties to follow the agreed upon procedures. These legal and administrative costs and any additional time, however, must be weighed against the well-documented risks of failure for any IT development project, especially e-commerce infrastructure projects. Inclusion of good project management procedures in the contract serves both the party developing the technology and the party acquiring it.

Lawyers should counsel clients to include the aforementioned project management principles in all e-commerce infrastructure development contracts or be prepared to take a serious and needless risk of project failure. No lawyer wants to see his or her client mentioned in the next article on failed IT systems. Advise your clients to contract accordingly.

(1.) E-commerce or e-business infrastructure means the Web sites and databases that provide Web-based offerings of products and services.

(2.) Philip Sheldon, Basic Errors Plague E-Commerce Sites, E-COMMERCE IN ACTION (May 29, 2002), at http://www.itworld.com/nl/ecom_in_act/05292002 (“Today’s Web site is truly an enabling technology, which allows transactions to be conducted electronically, lets customers search a retailer’s database of currently available stock, gives companies valuable marketing information on site visitors, and serves up custom pages in real-time that specifically match each visitor’s particular needs.”).

(3.) Id. (“Along with these innovations, however, comes complexity, and with complexity, the potential for error. When creating a dynamic Web site, for example, planning for every possible combination of events is almost impossible….”).

(4.) Scott Berinato, The Secret to Software Success, CIO MAG., July 1, 2001, at 77, available at http://www. cio. com/ archive/ 070101/ secret_content.html.

(5.) Id.

(6.) THE STANDISH GROUP INTERNATIONAL, INC., THE CHAOS REPORT (1994), available at http://www. standishgroup. com/ sample_research/chaos1994.pdf.

(7.) Id.

(8.) Id.

(9.) THE STANDISH GROUP INTERNATIONAL, INC., CHAOS: A RECIPE FOR SUCCESS (1999), available at http://www.steeltrace.com/download/chaos%20report%201998.pdf.

(10.) Berinato, supra note 4, at 2.

(11.) Capers Jones, Project Management Tools and Software Failures and Successes, CROSSTALK: THE J. OF DEF. SOFTWARE ENG’G, July 1998, at 15.

(12.) CHAOS: A RECIPE FOR SUCCESS, supra note 9, at 3. The Standish Group, author of the “landmark” study on project failure, says their research confirms that “small projects are much more likely to succeed than large projects.” Id. They propose a “recipe for success” of no more than six people for six months at a cost of no more that $750,000. Id. at 12.

(13.) Stewart Roby, E-continuity: How to Survive if You Rely on the Internet, available at http:// www. kpmg. co.uk/ kpmg/ uk/image/ fs37.pdf.

(14.) Matthew G. Nelson, Fast Is No Longer Fast Enough, INFORMATIONWEEK.COM, June 5, 2000, at 49, available at http:// www. informationweek. com/ 789/ web.htm.

(15.) Id.

(16.) Top 10 Corporate Technology Failures, available at http://www. fortera.com/44NfailChart.pdf.

(17.) Id.

(18.) Id.

(19.) Id.

(20.) Id.

(21.) Id.

(22.) Id.

(23.) Id.

(24.) Christopher Swope, Blame for a Fiasco, GOVERNING.COM (Mar. 13, 2000), available at http://www.governing.com/view/vu031300.

(25.) Famous Failures of Complex Engineering Systems (1997) (unpublished tutorial, California Institute of Technology), at http://www. cds.caltech.edu/conferences/1997/vecs/tutorial/Examples/ Cases/failures.htm.

(26.) Id.

(27.) Dan Verton, Conservative Year Ahead for IT Budgets, COMPUTERWORLD (Dec. 26, 2001) (citing a report by Giga Information Group, Inc.), available at http:// www. computerworld. com/ managementtopics /management/ story /0,10801,66958,00html.

(28.) GARTNER, INC., GARTNER PREDICTS 2002: TOP 10 PREDICTIONS 3 (2002), available at http:// www. adabasnatural4ever. com /industry_news/ media/ gartner_predicts_2002_top_10_predictions.pdf.

(29.) CHAOS: A RECIPE FOR SUCCESS, supra note 9, at 3.

(30.) Id.

(31.) Id. at 1.

(32.) THE CHAOS REPORT, supra note 6, at 4.

(33.) CHAOS: A RECIPE FOR SUCCESS, supra note 9, at 2 (“The best news is that project management is succeeding more often.”).

(34.) Jones, supra note 11, at 13.

(35.) BRUCE F. WEBSTER, PRICEWATERHOUSECOOPERS LLP, PATTERNS IN IT LITIGATION: SYSTEMS FAILURE (1976-2000) (PricewaterhouseCoopers study 2001), available at http:// www. pwcglobal. com/ extweb/ ncsurvres.nsf/ 0cc119c627d157d8525650600609c03/ 4e6d8a90e8ff9c7185256904005e9a93/ $FILE/ sys_fail_rept.pdf.

(36.) Peter Buxaum, See You in Court, COMPUTERWORLD, Mar. 26, 2001, at 43 (citing to the PricewaterhouseCoopers study), available at http:// www. computerworld. com / managementopics/ xsp/ strou/0,10801,58935,00.html.

(37.) WEBSTER, supra note 35, at 8.

(38. Id.

(39.) Id.

(40.) Put more bluntly, “the faster they work, the less money they make for a given assignment,” Marc Lauritsen, Its About Time–Break the Hourly Billing Habit, LAW PRAC. MGMT., Apr. 2002, at 27.

(41.) See WEBSTER, supra note 35, at 7 (“Too often though, clients, vendors and manufacturers sign contracts and agreements without having them reviewed by lawyers who understand IT-specific pitfalls.”).

(42.) All parties to the IT project should agree ahead of time to specific expectations, promises, and contingencies regarding … quality…. For example, the system specifications should include not just the required functionality, but should also spell out any performance requirements or constraints, compatibility requirements, anticipated lifespan, and acceptable levels of defects.

Id. at 3.

(43.) “Undefined expectations frequently lead to dreaded scope creep–in which an initially straightforward technology project is asked to solve more and more problems until it grows bloated and unmanageable. Scope creep, in turn, tends to flay schedules and eat up resources.” Steve Ulfelder, The Dirty Half-Dozen: Six Ways IT Projects Fail–And How You Can Avoid Them, DARWIN MAG., June 2001, at 4, at http://www. darwinmag. com/ read/ 060101 /dirty_content.html.

(44.) In 1995, the Standish Group estimated that “U.S. government and businesses spent approximately $81 billion on canceled software projects, and another $59 billion for budget overruns.” Lorin J. May, Major Causes of Software Project Failure, CROSSTALK: THE J. OF DEF. SOFTWARE ENG’G, July 1998, at 9.

(45.) Bill Nichols, Building Software in an Organized Fashion II, BYTE, Aug. 26, 1999, available at http:// www. byte .com/ documents/s=141/byt19990826s0021.

(46.) Id.

(47.) Id.

(48.) RICHARD BILLOWS, THE HAMPTON GROUP, INC., PROJECT PLANNING: THE REALLY CREATIVE AND HIGHLY POLITICAL FIRST STEP 1 (2001), available at http://www.4pm.com/articles/projplan.pdf.

(49.) Id.

(50.) Id. at 2.

(51.) Nelson, supra note 14, at 1.

(52.) Id. at 2.

(53.) Deanna Keahey, Self-Inflicted Scope Changes, PROJECT MAG. (Jan. 2002), at http:// www. projectmagazine. com/ jan02/ change4.html.

(54.) THE HAMPTON GROUP INC., THE FIVE DUMBEST THINGS A PROJECT MANAGER CAN SAY: WORDS THAT ALWAYS COME BACK TO HAUNT US (2000), available at http:// www. 4pm. com/ pmtalk03-19-01.pdf.

(55.) Some amount of scope change is natural for a project. No project exists in a vacuum

Keahey, supra note 53

(56.) Detailed specifications include both technical specifications and functional specifications. The functional specifications define the processes (features) the technology will perform and a set of technical specifications set forth the technical means by which the features will be implemented.

(57.) Even if the design document or developed software has been paid for in full, the copyright is owned by the designer or developer as the author of that work. Without a specific assignment or license of that copyright by the author, the author is free to use the work elsewhere. Mere payment, even of a large sum, does not confer any ownership or license rights.

(58.) The financial viability of every company should be examined and evaluated as part of the negotiation process. Although it is beyond the scope of this Article, the agreement should include numerous protections for both sides should one party either be acquired or face bankruptcy.

(59.) The intellectual property issues are critical and mostly outside the scope of this Article. These critical issues of ownership and licensing rights to intellectual property, which is the core asset of technology companies, must be addressed, resolved and memorialized in all aspects of technology development work including with employees, consultants, and potential and actual business partners.

(60.) PARSONS AUDIT TEAM, REPORT TO GOVERNOR JAMES E. MCGREEVEY ON THE STATE OF NEW JERSEY’S ENHANCED MOTOR VEHICLE INSPECTION CONTRACT WITH PARSONS INFRASTRUCTURE & TECHNOLOGY GROUP 19 (2002), available at www.state.nj.us/governor/final_parsons_report.pdf.

Thomas M. Laudise, Esq. and Leonard T. Nuara, Esq. *

Leonard T. Nuara, Esq. (lnuara@tpwlaw.com) is a partner with the law firm of Thacher Proffitt & Wood, chairs the firm’s Technology and Intellectual Property Practice Group and since 1986 has been an adjunct professor at Seton Hall University’s School of Law in New Jersey teaching computer and intellectual property courses. Thomas M. Laudise, Esq. (tlaudise@pwlaw.com) is a senior associate in the Technology and Intellectual Property Group at Thacher Proffitt & Wood. Prior to attending law school, Mr. Laudise earned his MBA degree while working as a software system analyst.