FindLaw | Find a Lawyer. Find Answers.

Corporate investments in software systems have an alarmingly high failure rate. Millions are lost on canceled projects and systems delivered late, over-budget, or without promised functionality. Many things explain this. Some of these problems can be alleviated through effective planning of the technical and management parts of projects, and the legal relationships with vendors as well. These steps will help avoid failures and provide meaningful recourse when failures do happen.

Corporate Investments In IT Systems

Enterprises of all sizes are making massive investments in mission critical computing systems. Increasing market pressure forces companies constantly to add and upgrade systems that quickly become obsolete by changing technology. Despite the heavy costs of acquisition, implementation, conversion, and maintenance of new systems, it is typically true that no change costs more than change. New products promise benefits in efficiencies and performance that exceed those costs.

Software products available to business users vary dramatically. Enterprise-wide systems offer to integrate a company's global manufacturing, financial, human resources and distribution operations. Competing operating and networking systems offer to serve as core enterprise backbones. Vertical applications offer to satisfy specific needs of a given industry.

Many products are packaged, but most require some customization to the user's needs. Most large projects require extensive custom development involving several vendors and the integration of multiple products. Of course, needs are never frozen and constantly change, often during a project's design or development. Once installed, systems require ongoing maintenance to correct errors and to adapt to new needs.

CEO's and IT executives face a bewildering array of questions in satisfying the information needs of the enterprise. What are the true needs? Which are mission critical? What hardware and operating and networking systems best meet them? Does everything I need work together? What platforms give management the most flexibility to adapt to future change and scalability needs? What applications add value? Which value/price points make the most sense? What is the true cost of ownership in any scenario?

These questions are compounded by the looming Year 2000 crisis, which imposes urgent priorities that compete with ordinary needs. On the other hand, this is a crisis most companies cannot ignore. It accordingly provides a unique opportunity to fully evaluate current systems and the value of overall system improvements. In many cases, noncompliant legacy systems are better replaced than repaired.

It is estimated that in the United States alone, companies spend more than 250 billion every year on IT application development of approximately 175,000 projects. The average cost of a development project for a large company is 2,322,000. ¹

The Risk Of Failure

Remarkably, investments of such magnitude carry an extraordinary risk of failure. The Standish Study found that:

• 31% of these projects will be canceled before they are completed;
• 53% will far exceed their original estimate;
• in 1995, companies and government agencies in the U.S. alone spent 81 billion for canceled projects and another 59 billion for projects completed late;
• only 16% are completed on time and on budget, and for large companies only 9% are so completed.

The kinds of damages suffered when a project fails include not only the out-of-pocket expenditures, but also operational downtime, lost opportunity costs, accelerated hardware obsolescence, conversions to substitute systems, loss of reputation and goodwill, and general damage to competitive standing.

Causes of Failure

Failures, of course, have many causes. The Standish Study estimates that on the user side, poor planning is, to no surprise, the chief culprit. Heading the list were lack of user input into the planning process and incomplete and changing requirements and specifications. If carefully defined, these requirements and specifications should guide and control the project. If properly incorporated into the legal contract with the vendor, they also become legally binding incentives and baselines to measure vendor performance. However, if poorly planned, the user loses control over the project and probably won't get what it wants.

Unfortunately, vendors sometimes oversell their capabilities. Vendors compete fiercely to establish market share and industry standards. Marketing personnel often commit to performance features and delivery dates without fully involving the vendor's development organization. More commonly, there is merely an honest disconnect between what the user truly needs and expects and what the vendor can truly deliver. These problems are exacerbated by the typical rush to complete the project. Post-development training support and maintenance, which are critical to overall project success, are frequently disconnected from the development process.

In many failures, the user is left with little recourse. For example, UOP, a joint venture of AlliedSignal and Union Carbide, is currently suing Andersen Consulting for 100 million for a software development project that was aborted. The case is new, but indications are that UOP's consulting contract with Anderson did not adequately define system specifications or provide other essential legal protections for the user, and Andersen is vigorously defending the suit on that basis.

Protecting Against The Risks

Good technical planning and project management are essential to project success. But they are usually not enough. Effective legal representation of the user in these transactions can help in two general ways: (1) to avoid failure, and (2) to create meaningful remedies if failure occurs.

The majority of these failures can and should be prevented through effective negotiation of the vendor relationship upfront. Companies typically invest in evaluating and planning the technology, with consultants or internal staff. However, in our experience, disproportionately little attention is devoted to the legal relationship. This is surprising for transactions of such magnitude.

Effective legal protection on the user side should be a win/win for all concerned. It is preventive, not reactionary, protection. By helping to define user requirements and product capabilities in a binding way, and by clarifying vendor commitments in performance, functionality, and scheduling, expectations will better match capabilities. Honest disconnects will be flushed out in the planning stages. By giving the user realistic back-end remedies in case of failure, the vendor is better motivated to succeed.

Users are typically disadvantaged in these transactions. Vendors have greater expertise, leverage, and sophistication in the area. The user, by contrast, is usually acquiring technology in an isolated transaction, apart from its core business, with which it is less familiar. It is also a reality that contract terms proposed by vendors are often imbalanced, sometimes extraordinarily so. Product claims which are made during the selling process are often disclaimed in the contract. The user's remedies are often limited. Vendors often strive to "close the deal" to shortcut negotiations, by offering special pricing or the availability of key personnel for only limited periods of time.

Ensuring Functionality

Before examining alternative solutions or talking to vendors, a corporate user should carefully examine its own information needs and develop its own business requirements. This exercise, initially technical, is essential to providing a critical legal protection. User needs should define the project, and solutions should fit the needs, not vice versa.

In general, the exercise should include at least the following steps:

• Identify problems with existing systems. A systems analyst will facilitate this.
• By all means, involve actual users in the review.
• Focus initially on what is needed, not how it is to be accomplished.
• Develop a list of requirements written in terms of functional end-results, using business language.
• Review possible solutions from a top-down viewpoint. Partition the problem into manageable components, and work towards concrete, measurable detail.
• Throughout the process, try to measure the monetary benefits expected to be realized by the change. This will help determine whether value outweighs cost and will be important for later price negotiation.
• Include performance measurements such as maximum response times and hardware configurations as part of the total system requirement.
• Include a conversion plan to migrate from the existing system to the new one, if applicable, including "cost of ownership" elements such as new skills, training, and personnel that may be required.
• Identify likely future needs as well, such as increases in data volume and hardware upgrades. Current design should accommodate future scalability, portability, and flexibility requirements.

This listing will serve as the "user requirements" baseline for the evaluation and development of software solutions and for negotiations with vendors. Ideally, requirements will be frozen until the project is completed, but in practically all cases this is not realistic. However, the means for facilitating system changes should be planned and controlled.

The user requirements should guide the evaluation of vendor solutions. Through requests for proposal or otherwise, prospective vendors should be asked to identify precisely its ability to meet each requirement. Any qualifications should be fully explained. It is important legally that prospects be told upfront that their responses will eventually be reflected in their performance warranties in the consulting or license agreement. Vendors tend to resist this, preferring instead to warrant performance only against their own published specifications and documentation. Typically, vendors will not be able to commit to satisfying all user requirements. The corporate user accordingly will have to reassess and compromise its requirements.

During this selling and evaluation stage, the user should make a careful record of all vendor performance claims. These claims might be made in a variety of ways, such as in sales correspondence, marketing pieces, product demonstrations, and oral statements. Written copies of all claims should be maintained. Oral statements should be memorialized. They may later serve as the basis for a legal remedy. Vendor marketing claims also serve the important purpose of testing the formal responses to an RFP. Inconsistencies should be fully explored.

The end result of this process will be a detailed listing of "specifications," in clear, objective terms. These should serve as the vendor's performance warranties in the operative agreements. Vendors should also warrant performance according to its standard documentation, with the understanding that the specifications will prevail in case of any conflict.

As mentioned above, vendor marketing personnel sometimes commit to performance, functionality, or delivery dates without adequately involving other critical parts of the development organization. Accordingly, if possible, the corporate user should require the vendor's development, documentation, implementation, and maintenance teams to also review and approve the specifications and other commitments made by marketing personnel. This is a preventive step to avoid failures.

The primary benefit of this specification definition exercise is to match the user's needs with the vendor's capabilities. This will avoid the "honest disconnect" and provide standards for judging any failures. The vendor will have clear requirements to satisfy, and will be incentivized to do so by the conspicuous strength of the user's legal remedies.

Implementation

As the project or its parts are completed, the system will undergo critical installation and testing. The corporate user should require the vendor to use samples of its live data in pre-installation testing, and to allow the user to participate in that testing. The vendor should be required to deliver automated test suites for all software provided, for validation at the user's site.

It is critical that the operative agreements provide for adequate acceptance testing and procedures which the user - not the vendor - will control. Vendors sometimes want to control the ultimate testing, better to ensure the result. This should be resisted.

The software should be tested against the specifications using live data, typical of the type and volume anticipated in the production environment, by actual users over at least one full business cycle. This period of time will vary from case to case. Error detection procedures should follow customary software engineering practices, in which users focus on areas of highest risk and greatest consequence of failure.

Final system "acceptance" should not occur until all material errors and defects are corrected. A procedure should be established in the agreement for the notification of defects, correction, re-delivery, re-test, etc., until all material errors are fixed. In multiple vendor projects, third party licensors should also be required to commit to these procedures.

If at some point during this process the errors cannot be corrected, the corporate user should be able by the terms of the license to return the software and recover its total cost of the project. Again, these are prudent preventive steps. Effective testing at the outset will help avoid failures and will be far more meaningful to the user than having legal remedies after a failure has occurred and the damage is done.

Other Legal Protections

There are a variety of other important things the corporate user should consider in order to maximize the chances of success:

(a) In many ways, corporate users often have more leverage with the vendor than they may think. If the user retains meaningful options, whether they be competitive solutions or no change at all, the vendor will be motivated to negotiate. In many situations, vendors want to procure a "showcase" installation - a success story - for marketing purposes. And, as in all cases, it benefits a vendor immensely to have happy customers. All of these are sources of leverage.

(b) User payments should be based on milestones tied to conforming deliverables. A meaningful portion of the total fee should be tied to final acceptance.

(c) Clear, measurable commitments should be obtained from the vendor in critical service areas such as installation, data conversion, training, support, and ongoing maintenance. Maintenance costs should not commence until the expiration of the applicable warranty period.

(d) In cases of multiple vendors, ultimate responsibility for the project should rest on the prime vendor. Subcontractors and third party vendors should be identified and approved, and their commitment to develop, test, and maintain their components should be stipulated. Third party sublicense agreements offered by the prime vendor should be negotiated as necessary to fit the user's needs.

(e) The software license, consulting, equipment purchase, and service agreements, as applicable, should be balanced and effective in all other respects. They will typically require substantial re-negotiation from the standard vendor forms, in such areas as warranties and warranty disclaimers, limits on vendor liability and user remedies, and dispute resolution.

(f) Price itself is notoriously negotiable. Vendor pricing strategies can be bewildering. Fees can be spread among the software license, hardware, custom development, implementation, training, and maintenance. Vendors typically earn substantially greater margins in some areas than in others.

(g) Effective legal protection does not end when the contracts are signed. They need to be effectively implemented and enforced. This process is loaded with legal pitfalls for the user, as many rights can be lost for failure to notify the vendor of defects or otherwise assert claims in a timely and proper fashion, as contemplated by the agreements.

(h) Clear and effective dispute resolution remedies for the corporate user hopefully will never have to be used. However, their mere existence is a strong deterrent against nonperformance. The objective in any project is not a "good" lawsuit, but a system that meets expectations, on time and on budget. Effective legal remedies for failure, coupled with strong resources from experienced user counsel, will help motivate the vendor to perform.

(i) User remedies are often better than even bad contracts might appear to provide. The law in many states creates remedies in many cases despite contrary pro-vendor language in the written agreements.

Summary

Experienced counsel for the corporate user in the planning stages of a software project will help avoid failures. Given the alarmingly high risk of failure, waiting until the project is in trouble to bring in counsel is often too late. By that time, rights and remedies are usually determined.

---

Data provided by The Standish Group, a market research and advisory firm based in Dennis, Massachusetts, in its publication "Chaos," 1995 (the "Standish Study").

Ads by FindLaw