Today's businesses are totally reliant on a firm's information technology and management systems. Indeed, with the evolution of e-commerce, many businesses conduct most or all of their business operations through an integrated systems environment. Delay in implementation, upgrade or failure of these systems can be catastrophic for these firms.
Whether a company is privately or publicly held, these systems provide the data necessary for critical reports. Boards of directors and senior management rely on the firm's information management systems to make virtually every decision regarding the application of the firm's human, financial and tangible resources.
Information technology and management systems comprise a substantial percentage of most firms' capital expenditures and give rise to substantial recurring expense. And should the business become involved in a legal or regulatory dispute, the preservation and production of the data creates an increasing demand on legal budgets. Severe penalties can be imposed on any organization that does not properly perform its data handling responsibilities in litigation or in response to regulatory investigations.
Disputes Can Be Costly
Given this significance, it comes as no surprise that disputes frequently arise between and among the purchasers of information management systems and the industry vendors. Disputes arise (i) between the business enterprises that buy these systems and the suppliers of hardware; (ii) between buyers and the suppliers of both platforms and specialized application software; (iii) between buyers and consultants who assist them in vetting and acquiring such systems; and (iv) between and among all of the above and the so called systems "integrators." Disputes in this industry may involve the technical merits of the hardware or software. Additionally, and with increasing prevalence, disputes may center on issues that are the subject of an entirely different discipline - project management.
And do such disputes ever occur! According to U.S. government statistics, in 2004, American companies spent $947.6 billion investing in new or replacement hardware or software. According to the Standish Group over 71 percent of such contracts failed to meet contract budgets, requirements or time limits. Experience teaches that budgeted cost and time targets are overrun by substantial margins.
What Is Being Bought Is Not What Is Being Sold
This shocking contract failure rate underscores some obvious points: "What is being bought is not what is being sold."
Buyers should beware of the word "solution," a seemingly ubiquitous term in this arena. The word "solution," used in the abstract, has no semantic "referent." It is a pure mental construct, a "feel good" expression. Yet vendors purport to sell "solutions" as if they were real. And boards of directors buy "solutions" as if they really exist. But they don't.
In legal terms, when a purchaser buys a real thing, the purchaser obtains legal rights and opportunities to sue. Boards of directors, municipal commissions and authorizing agencies frequently demand representations of what general functions an information management system will ultimately perform and a fixed or "not-to-exceed" delivery price. Unless these assurances are given, the decision makers will not authorize the expenditure. Salesmen for vendors and sometimes heads of IT departments typically seek to persuade decision makers to authorize the expenditure by speaking of the system's "functionality" as providing a "solution," as if these terms mean something specific. They do not.
These days, information management contracts frequently state that the vendor is not selling a "thing" - what we call a "good," in legal terms - but rather providing a "service." This means that all the legal rules about implied warranties do not apply, even though the contract will frequently still speak in terms of the supply of a "solution." When a "service" is being purchased, different and less familiar legal rules apply than are applicable to the purchase of goods. Whether a good or a service, the purchaser must be aware that the vendor has made a substantial investment in the contract's language to make sure its provisions are likely to be resolved against the customer.
If the goal is to custom develop software from scratch, by definition the "solution" is not even known at the time of contracting. The "solution" may (or may not) emerge only after a lengthy period of business analysis, drafting, detailed programming and testing. Alternatively, as is often the case, the customer buys software "off the shelf" and commits to change the business to match the software as much as possible. The business is left to engrafting specialty application software onto a base (requiring "interfaces" and "extensions") or even, worst case, undertake "modifications" or "customizations" of the underlying software. Even in these cases, the "solution" - the ultimate functionality the business really requires - is not even remotely in existence when the contract is formed.
Thus, what is really being negotiated and agreed to is not a pre-existing "solution," but something akin to a "fast-track design/build" contract occasionally used in the construction industry. Drafting such contracts properly requires special expertise and is critically dependent on the project management contract terms. Drafting such agreements and their administration requires special expertise. Managing the contract is thus frequently a walk on a tightrope between the law and events "in the field."
The Purchase Price May Not Appear To Warrant Specialized Legal Expertise
Rarely is a board or other authorizing authority aware of the specialized nature of information management and systems integration contracts. Purchasers often think a "solution" is being purchased and that their legal staff and IT officers can easily protect them. Many vendors, mindful of the authorizing body's budget, will scale back the initial phase of a project with the hope that the entire project will be expanded later under a new authorization if the initial phase meets expectations as later reinterpreted. Vendors frequently regard the opportunity to provide service updates, adjustments, custom coding, and integration to be as lucrative as the base purchase.
Thus, just as the contract itself is skewed against the consumer once the contract is correctly seen as a services contract, so are the dynamics of the negotiation itself. The services to be provided by the vendor are frequently scaled back during the negotiation phase to reflect the client's budgetary constraints. At the same time, rarely is it emphasized to the decision maker that at some point after the implementation is begun - and after millions of dollars in cash and human resource time may have been expended - the contracting body will again be called upon to make a "go" or "no-go" decision to either continue or abandon the project because the "solution" that is really needed cannot be achieved within the contemplated budget or anything close to it. Here again, independent specialized advice should be employed.
Non-Specialized Staff Rarely Has The "Clinical Experience" Needed To Analyze The Proposed Contracts That Vendors Submit In A Plain-Vanilla Form
The vendor's form language information management contracts seem facially reasonable to a novice. Form contracts may appear to pass legal muster, but the important details lie in complex exhibits and "statements of work" which exist at the intersection of law and expertise in project management. Moreover, attempts by the purchaser's in-house counsel to tinker with, to explain, or to expound upon the form contract invariably encounter tremendous push-back. The vendor's agents insist such language is "standard," "required by our general counsel" or a "deal breaker." For example, provisions limiting the liability of non-professional consultants and vendors and even professional consultants to the forfeiture of their fees are common.
But what is less understood is how the vendor's typical contractual provisions place enormous pressure on the customer to fulfill substantial "cooperation" obligations built into the contract. These obligations place real demands, not only on ultimate users and middle management employees, but frequently also on senior management to deliver the necessary "cooperation." From a legal perspective, such provisions arguably require the customer to document in detail that such cooperation has in fact occurred. They likewise place enormous pressure on the client's review and approval of critical project "deliverables" which, legally speaking, alone define the "solution." Moreover, the limitations of liability often provide additional pressure to stick with the purchase commitment even under circumstances of minimal product performance. The business cost of rolling back to previous systems coupled with the mere refund of the purchase price is not a welcome scenario. The deliverable review and approval process all too frequently proceeds in an atmosphere of stress, legal posturing and mutual recrimination.
Conclusion
Information management integration and software development contracts are unique. The extraordinarily high failure rate of these projects is due to a combination of legal factors and negotiating dynamics, with much of the negotiation necessarily proceeding post-contract execution. The perceived advantages of having a "solution," a naïve belief in the strength of contracts, budgetary considerations, ignorance of the seriousness of the client's cooperation and supervision obligations, and the desire to stick with the "solution" to make it work because of liability limitation provisions all contribute to the dismal statistics. The costs of wasted investment, lost productivity, career damage, unfulfilled expectations and legal fees and settlements are substantial. To avoid these dire results, legal counsel with special expertise in these projects should be employed at the contract's negotiating stage, not to create an atmosphere of confrontation, but to guarantee to the greatest extent possible that the actual decision makers truly understand what is involved and plan appropriately.
Published January 1, 2006.
