Client Insights
When an ERP Implementation Starts to Fail
Oct 09, 20268 min read
By Varant Yegparian
There is a popular fable about boiling a frog. Drop a frog in boiling water and it will immediately jump out. But put it in lukewarm water and slowly turn up the heat, the story goes, and it will remain until it is too weak to escape.
Failed software implementations can follow the same dynamic. Deadlines slip. Work expands beyond the original scope. The rollout shrinks to fewer locations. The client accommodates each setback as a seemingly sensible decision in the service of getting the project completed. The business has understandable reasons to keep the implementation going because it needs the system to work. Its people have invested months in the project, and replacing the consultant may mean more expense and delay. And each proposed fix offers a way forward. Together, however, these decisions can leave the client paying substantially more for considerably less, with few practical alternatives. At each turn, the water temperature slowly rises.
Research illustrates how often ERP projects fall short. A 2019 McKinsey article reported that three-quarters of enterprise resource planning (“ERP”) transformation projects failed to stay on schedule or within budget. Gartner’s 2024 research predicted that, by 2027, more than 70% of recently implemented ERP initiatives would fail to fully meet their original business goals. These are different measures of underperformance, neither limited to outright project collapse. A system may eventually work and still arrive late, cost more, or deliver less than the business expected.
It is not difficult to see why businesses should be focused on this dynamic. ERP systems are increasingly functioning as the backbone of operations. Without a functioning system, a business can easily fall apart. But the need for a functioning ERP system must be balanced with the statistics that show that nearly three-quarters of implementations fail to meet their intended goals. And the propensity for an implementation to fail fuels the exorbitant funds often spent to get these projects back on their intended timelines and headed toward their intended goals. Simply put, ERP implementations are heavily fraught necessities that can cost millions of dollars while also veering off track.
What can the client do before the water reaches a boiling point? Withholding payment may give the consultant a breach claim or a right to suspend work. Continuing to pay and approve revised scopes may create a different problem: the documents can begin to describe a project materially different from the one the client believes it bought. If the client ultimately abandons the implementation, contractual limitations may substantially restrict its ability to recover what it spent. The remainder of this article is intended to provide clients with a way out of the cooking pot.
Whenever an ERP implementation begins to become derailed, the first request made of the business implementing the system is often for approval of some additional scope of work that allegedly is necessary to address some hidden problem not foreseen during the initial stages of the implementation. When approached with a request to approve additional scope, the first question the client should ask is whether it is paying for new work or paying again for work the consultant already promised to perform. The answer requires examining both the contract and the project’s history. That review should begin when repeated delays, additional charges, or reductions in functionality materially change what the business expects to receive. The client can continue working toward completion while counsel assesses the effect of those changes.
Start with the original scope. What functionality was the consultant supposed to deliver, by when, and for what price? Compare the master services agreement (“MSA”) and supporting statements of work (“SOWs”) with the work completed and the proposed changes. If a new charge concerns functionality already included in the original scope, the consultant should explain why additional payment is warranted. If the client has added requirements or failed to supply necessary data, testing, or decisions, those facts must be reckoned with.
The distinction between original and new scope can disappear in the effort to rescue the project. The business approves a revised schedule because the old one is no longer achievable. It accepts a smaller rollout because some functionality is better than none. It signs another SOW because the consultant insists that completion requires it. Each change incrementally nudges the original project in the direction of becoming something different and often more costly. And so, before signing, the client should identify what the new document changes: the work owed, the completion date, the price, or the remedies available if the next attempt fails.
Review approval emails, acceptance records, invoices, testing results, and project reports alongside the agreements. Did the client accept the work as complete, or identify defects that remained unresolved? Did it approve a new requirement, or authorize an attempt to correct an existing failure? The record should accurately distinguish those decisions. A general complaint that the project failed is less useful than a documented account of what was promised, what was delivered, and what remains defective.
The available remedies begin with the consultant’s actual contractual commitments, with a specific focus on what the consultant actually promised to provide the client. A general obligation to perform services competently presents a different proof question from an obligation to deliver specified functionality by a stated date. A promise that software will work “out of the box” is difficult to evaluate without identifying the functions, integrations, and configurations it covers. Counsel must connect each claimed failure to an obligation the consultant actually undertook.
Warranty provisions also require attention. What was warranted, for how long, and subject to what notice requirements? Must the consultant receive an opportunity to correct the problem? Does the contract make correction of faulty work the exclusive remedy for a warranty breach, and does that restriction extend to other claims? A warranty may sharply limit relief, but its existence alone does not determine every available claim or remedy.
Damages provisions can leave a substantial gap between the client’s loss and its potential recovery. Is liability capped at the total project fees, fees paid during a particular period, or fees under only the disputed SOW? Which claims fall within the cap, and what exceptions apply? A consequential-damages waiver also requires careful reading. Lost profits are not invariably consequential damages; their classification can depend on how the loss arises, and a contract may exclude them separately. Repair costs, business interruption, and lost revenue must each be evaluated under the actual language and governing law.
Before withholding payment or terminating, identify the disputed invoices and the provisions governing payment disputes, notice, cure periods, suspension, and termination. Determine which amounts remain payable and what procedures apply to the contested charges. Choice-of-law, forum-selection, and arbitration provisions also matter: they affect the rules governing the dispute and where it must be resolved. The business then needs to assess what a suspension would mean for access to its data and its ability to operate.
Given the frequency with which an implementation fails to meet its intended purpose, MSAs are often drafted with severe restrictions on a client’s ability to bring contractual claims. The foregoing section detailed what those restrictions often look like. And so, clients seeking to litigate a failed implementation often look to extra- or non-contractual theories, like fraud or fraudulent inducement. Those claims require specific proof; a failed implementation does not, by itself, establish fraud. Rather, the client must show that it relied on material misrepresentations concerning the ERP system. But MSAs often have provisions addressing representations made outside the four corners of the applicable contract, especially merger clauses and disclaimers of reliance. These provisions warrant special attention because they are often at the heart of a lawsuit over a failed ERP system.
A standard merger clause establishes that the writing contains the parties’ entire agreement. Standing alone, it does not defeat a fraudulent-inducement claim. An enforceable disclaimer of reliance, by contrast, can negate the reliance necessary to recover for particular misrepresentations. The Texas Supreme Court explained that distinction in Italian Cowboy Partners v. Prudential Insurance Co.. The wording and the circumstances surrounding the agreement matter.
IBM v. Lufkin Industries illustrates the consequences of these types of provisions in a failed ERP implementation. In that case, after nine project-change requests and repeated delays, Lufkin went live with a system that could not invoice customers or perform other essential functions. It delayed public financial reporting and paid another $7.5 million to salvage the system. Nevertheless, the Texas Supreme Court held that Lufkin’s reliance disclaimers barred its fraudulent-inducement claims. The court ordered a new trial on the contract claim; the disclaimers did not eliminate every possible recovery.
The court considered the contractual language, the negotiations, representation by counsel, business sophistication, and arm’s-length dealing. Lufkin argued that the disclaimers were unnegotiated boilerplate. The court rejected that argument: the disclaimers’ enforceability did not require negotiation of every sentence; Lufkin had negotiated other deal points; and it did not contend that it could not have negotiated the disclaimers. Therefore, a client should not assume that an unread or unedited provision is unenforceable merely because it appeared in the consultant’s form. Lufkin, pp. 7–8 & n.4
The later change requests were equally consequential. Lufkin alleged that IBM’s continued assurances induced it to accept delays and pay more. But each change authorization incorporated the existing agreements, reaffirming the disclaimer of reliance. That defeated the later “string-along fraud” claim as well. A document intended to rescue a project can therefore also restrict the client’s ability to recover for the assurances that prompted it to sign. Lufkin, pp. 14–16
The provisions addressed above are not exhaustive. They show why legal review belongs at the beginning of the engagement and should resume when the project materially departs from the agreed scope, schedule, or price. Waiting until the business is ready to sue may leave counsel evaluating rights the client has already given up.
Deal counsel can help put the consultant’s commitments into specific, measurable terms and negotiate meaningful remedies if those commitments are not met. The agreements should address access to data, configurations, documentation, and completed work, including what happens if the client replaces the consultant. They should also distinguish the implementation consultant’s obligations from the software provider’s. A right to terminate one relationship does not, by itself, resolve the practical or contractual requirements for continuing the other.
Trial counsel can assess whether the evidence supports the client’s account, identify shortcomings in the client’s own performance, and advise on notices, payment disputes, and proposed amendments before those decisions become exhibits. Deal counsel, trial counsel, and the project team can then evaluate whether the next proposed fix advances completion on acceptable terms. The client still needs a functioning system. It also needs to understand what it is paying for, what it is agreeing to, and what recourse remains if the next fix fails.