Document 6515639

Reprinted with permission from The Business Lawyer, Vol. 58, No. 1, November 2002. Copyright
2002 by the American Bar Association. The material contained herein represents the opinions of
the authors and editors and should not be construed to be the action of either the American Bar
Association or the Section of Business Law unless adopted pursuant to the bylaws of the
Association. Nothing contained herein is to be considered as the rendering of legal advice for
specific cases, and readers are responsible for obtaining such advice from their own legal counsel.
To request reprint permission, contact the Manager, Copyrights and Licensing, at 312-988-6102.
How To Contract for a Successful E-Commerce
Development Project: Beating the Odds
By Thomas M. Laudise, Esq. and Leonard T. Nuara, Esq.*
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 in-
* Leonard T. Nuara, Esq. ([email protected]) 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. ([email protected]) 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.
1. E-commerce or e-business infrastructure means the Web sites and databases that provide Webbased offerings of products and services.
299
300 The Business Lawyer; Vol. 58, November 2002
tegrating 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; third-party software is usually brought in, as are consultants. As the effort
becomes increasingly complex, the risk of failure increases dramatically.3 It is no
secret that cost overruns, delays, poor functionality, technical malfunctions, and
even project cancellation are more the rule than the exception for projects involving technology development and implementation.
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;9 project failure is still the norm rather than the
exception. Estimates are that ‘‘[a]lmost three-quarters of all software development in the Internet era suffered from one or more of the following: total failure,
cost overruns, time overruns, or a rollout with fewer features or functions than
promised.’’10
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.
How To Contract for a Successful E-Commerce Development Project 301
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
11. Capers Jones, Project Management Tools and Software Failures and Successes, CROSSTALK: THE J.
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.
OF
302 The Business Lawyer; Vol. 58, November 2002
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
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.
How To Contract for a Successful E-Commerce Development Project 303
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; most will fail
for lack of skilled project management.’’31 The 1994 Standish report lists factors
impacting project success in this order: user involvement, executive management
support, clear statement of requirements, proper planning, realistic expectations,
smaller project milestones, competent staff, ownership, clear vision and objectives, and hard-working, focused staff.32
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; and
• Work with vendor to achieve the desired goal.36
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/0cc1191c627d157d8525650600609c03/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.
304 The Business Lawyer; Vol. 58, November 2002
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-theshelf ’’ 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.
37. WEBSTER, supra note 35, at 8.
38. Id.
How To Contract for a Successful E-Commerce Development Project 305
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
39. Id.
40. Put more bluntly, ‘‘[t]he 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.
306 The Business Lawyer; Vol. 58, November 2002
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?’’
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.
How To Contract for a Successful E-Commerce Development Project 307
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
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/s141/byt19990826s0021.
46. Id.
47. Id.
308 The Business Lawyer; Vol. 58, November 2002
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 ecommerce 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
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.
How To Contract for a Successful E-Commerce Development Project 309
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
ORDER PROCEDURE
WITH A
CHANGE
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 deliver-
54. THE HAMPTON GROUP INC., THE FIVE DUMBEST THINGS A PROJECT MANAGER CAN SAY: WORDS
ALWAYS COME BACK TO HAUNT US (2000), available at http://www.4pm.com/pmtalk03-1901.pdf.
55. Some amount of scope change is natural for a project. No project exists in a vacuum; the world
around it keeps changing. It is common that shifts in the external business environment result
in a valid need to change the project scope. The longer the project, the more likely this becomes.
THAT
Keahey, supra note 53; see also Jones, supra note 11, at 16 (‘‘The average growth of unplanned,
unanticipated requirements is about 1 percent to 2 percent per month during the design and coding
phases of typical software projects, although the upper range of requirements creep can exceed 10
percent in a single month.’’).
310 The Business Lawyer; Vol. 58, November 2002
ables 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.
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.
How To Contract for a Successful E-Commerce Development Project 311
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.
312 The Business Lawyer; Vol. 58, November 2002
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.
How To Contract for a Successful E-Commerce Development Project 313
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 nonexclusively 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
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.
314 The Business Lawyer; Vol. 58, November 2002
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 rights 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
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.
How To Contract for a Successful E-Commerce Development Project 315
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
316 The Business Lawyer; Vol. 58, November 2002
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.
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.