When Enterprise Software Fails: What General Counsel Should Know Before the Lawyers Get Involved

Enterprise software implementations are among the largest financial commitments an organization makes. A new ERP, CRM, HCM, or supply chain platform can cost tens of millions of dollars, sometimes hundreds of millions when you account for the full scope of licensing, system integration, data migration, change management, and organizational disruption. These projects reshape how organizations operate at a fundamental level.

They also fail at an alarming rate. Gartner is often misquoted as saying that more than 70% of all ERP implementations will fail. In fact, what Gartner has been saying for over a decade is that more than 70% of ERP implementations fail to meet their original business goals. That distinction matters because it points to something more nuanced than broken software. It points to a gap between what was expected and what was delivered, between what the contract defined and what the business needed. 

A significant percentage of these projects result in litigation: breach-of-contract claims, trade secret disputes, class action matters, and regulatory proceedings that can dwarf the original project cost.

I’ve spent 35 years in enterprise IT as a CIO, a VP of Enterprise Architecture, and a program executive delivering implementations ranging from $5 million to $150 million. I’ve also spent more than a decade as an expert witness and litigation consultant, retained in more than 30 matters involving enterprise software disputes. I’ve been retained by customers who believed their vendor failed to deliver, and by vendors who believed they delivered exactly what was contracted. Both sides are often telling their version of the truth.

That combination, delivering implementations and then analyzing why similar ones fail, has given me a clear view of what separates successful projects from those in dispute. The difference is rarely the technology. It’s whether the people who could prevent failure were in the same room at the right time. 

This article synthesizes the framework I’ve developed from that experience. It’s written for General Counsel at organizations implementing enterprise platforms, and secondarily, for litigation attorneys evaluating experts in technology disputes. But the patterns apply to anyone involved in governing these programs. 

How Enterprise Software Projects Fail

When people hear “software failure,” they assume the code was bad. In reality, most implementation failures stem from organizational, contractual, or governance breakdowns, not technical shortcomings. Across the matters I’ve analyzed, five failure modes recur with striking consistency. The first three have nothing to do with code.

1. Contractual ambiguity

The most common source of enterprise software disputes isn’t bad software. It’s a scope definition that two reasonable parties can read differently. What does “delivered” mean? What counts as “customization” versus “configuration”? When the contract says the vendor will deliver a “fully functional” system, does that mean functional against the written requirements, or functional in the way the business actually operates? These aren’t hypothetical questions; they’re the questions I get asked in depositions. Neither party acted in bad faith. Both read the same document and saw different obligations. 

2. Governance vacuum

Enterprise implementations require hundreds of decisions on requirements, design trade-offs, and scope boundaries. When there’s no clear governance structure, no steering committee with decision-making authority, and no change-control process that both parties respect, decisions get made informally, inconsistently, or not at all. I’ve seen customers lose cases because they couldn’t demonstrate that they’d fulfilled their own governance obligations. And I’ve seen vendors lose because they proceeded without documented approval on decisions that materially changed the scope.

3. Requirements drift

Every enterprise implementation changes after kickoff. That’s normal. The failure isn’t that requirements change; it’s that the changes aren’t formally documented, priced, and approved. Customers add requests without understanding the schedule and cost impact. Vendors absorb changes to preserve the relationship, then later claim they were out of scope when the budget runs dry. The result is a project in which the original statement of work no longer describes what’s being built, yet nothing has replaced it as the governing document. 

4. Integration blindness

Enterprise platforms don’t operate in isolation; they connect to payroll, CRM, data warehouses, and legacy systems that no one fully understands anymore. Integration is where assumptions get tested. And in too many implementations, those assumptions aren’t tested until late in the project, when the cost of being wrong is highest. This failure mode is technical, but its root cause is usually organizational; it’s a planning failure for which the architecture team, the vendor, and the PMO all share responsibility. 

5. Vendor capacity mismatch

The A-team sells the deal. The B-team delivers it. This is the failure mode that vendors least want to talk about, and customers most want to litigate over. But fairness requires acknowledging the other side: customers also create capacity mismatches by assigning their best people to “keep the lights on” in the legacy environment while staffing the new implementation with whoever is available. Both parties underestimate the sustained human investment these projects require.

My professional experience has involved all sides of this equation: the system integrator using the financially necessary flexible capacity approach with subcontractors, the consulting firm providing junior resources to reduce costs and strengthen credentials, the independent contractor offering deep expertise on demand, and the customer struggling to staff subject-matter experts and maintain legacy systems for both technical and business needs.

In every single failure mode, both parties contributed. Enterprise implementations are fundamentally a shared responsibility.

That principle, shared responsibility, is the thread that runs through every pattern I’ve described. The vendor can’t succeed without an engaged, decisive customer. The customer can’t succeed without a vendor that delivers transparently against defined commitments. When that shared responsibility breaks down, the result isn’t just a troubled project; it’s a dispute where both sides can make a credible case.

The Definition Problem

One of the most consequential dynamics in enterprise software disputes is that “failure” doesn’t have a shared definition. Three competing standards are typically at play, and they rarely align.

Contractual success is the vendor’s standard: did we deliver what was specified in the statement of work? The acceptance criteria were met. Testing was completed. The system went live. This is often a defensible position, but contractual success can coexist with operational failure. 

I recall a case where a customer provided 3,500 detailed requirements, all of which were delivered as user stories with traceability evidence showing they had all been tested and completed. However, at go-live, the enterprise system failed because the end-to-end processing and interoperability didn’t function. Although all requirements were met individually, the enterprise-level system did not operate successfully. I refer to this as the “watermelon effect”: all indicators are green on the surface, but everything is red internally. 

Operational success is the IT and operations standard: does the system actually work in our environment, with our data, at our scale, for our users? A system can pass acceptance testing and still fail operationally. But operational failure isn’t always the vendor’s fault. Customers who under-invest in testing, compress user acceptance timelines to meet an arbitrary go-live date, and don’t allocate their own subject-matter experts to validate the system contribute to operational failure as much as any vendor shortcoming.

Business outcome success is the executive sponsor’s standard: did this investment deliver the results we were promised? This standard matters most to leadership, and it’s almost never defined in the contract with any specificity. The business case was written by the customer’s own team, often with vendor encouragement, and the projected benefits were aspirational. The vendor didn’t write the business case, and the contract typically doesn’t guarantee business outcomes; it guarantees software delivery.

The disputes I analyze take several forms. Some involve projects that were canceled before delivery, where the customer terminated for failure to perform, and the vendor contends the customer’s own delays, requirement changes, or governance failures caused the schedule to slip. Those cases are rarely as simple as they appear, because both sides usually contributed to the delay, and the question of who caused the project to fail becomes the central point of contention. Other matters, often the most complex, involve systems that were delivered but didn’t work as the customer expected, or worked as designed but not as needed. 

In both cases, the root cause is the same: the definition of success was never jointly established in terms that both parties understood and could measure.

Why the Contract Isn’t Enough

Organizations rely on the vendor contract as their primary safeguard against implementation risk. The contract is essential; it defines obligations, allocates risk, establishes remedies, and creates the legal framework governing the relationship. But the contract operates after the fact. It defines what happens when things go wrong. It doesn’t prevent things from going wrong.

Certain contractual provisions look protective on paper, but function differently in practice than most parties expect. Acceptance testing frameworks only validate what’s been defined, and the definition of success is often incomplete. Limitation of liability clauses cap the vendor’s exposure, but the customer’s actual damages may far exceed that cap. Escalation procedures fire too late; by the time the contractual threshold triggers, the project has been in trouble for months. Warranty periods cover defects against specifications, not the gap between what was specified and what was needed. 

None of these provisions is poorly drafted. They do what contracts are designed to do: define rights and remedies. The gap is that no contract can substitute for the ongoing operational governance that actually prevents failures from occurring.

I have worked with GCs at both ends of the spectrum: some who insist on restrictive contract language that only drives up vendor costs, and others who try to manage the vendor’s delivery directly. In these cases, I have seen projects fail. Success tends to come from engaged GCs who ask pointed questions when drafting the contract and stay connected not just to the PMO but also to the architecture team, those who know best about the software delivery. 

The organizations that avoid litigation aren’t the ones with the strongest contracts. They’re the ones that built operational governance alongside the contract and treated both as essential. 

The Rosetta Stone Problem

Before cross-functional governance can work, there’s a prerequisite that most organizations overlook: legal teams and technology teams don’t speak the same language.

The same words, used in the same documents, carry materially different meanings depending on who’s reading them. “Deliverable” means something different to a contracts attorney than to an architect. “Customization” means something different to a QA lead than to a procurement officer. “Integration” can represent a week of work or a year of work, depending on what the parties assume. “Go-live” means the system is in production. It does not mean the system is ready, users have been trained, or integrations are stable under load. 

This isn’t a problem of carelessness. Legal professionals are precise by training. Technology professionals are precise by necessity. The issue is that they’re precise in different domains, using different frameworks, and they rarely have enough exposure to each other’s domains to recognize when a term that feels clear to them is ambiguous to the other side.

The solution isn’t to make lawyers into technologists or architects into attorneys. It’s to ensure that someone in the process can operate in both domains: someone who can read a statement of work and identify where a term that sounds definitive to the legal team is actually ambiguous to the delivery team, or where a technical assumption that seems routine to the architect creates material contractual exposure.

Across the dozens of organizations I’ve led or advised, I have seen a wide range of approaches by the GC to this gap. In some cases, IT leadership and the GC may not recognize that architects should be included in the contract review, creating a translation gap. The reasons vary, but the results are consistent. In other cases, I have seen architects partner directly with the GC and the stakeholders during the procurement cycle to achieve good results.

The Implementation Risk Triad

Every problem I’ve described traces back to the same structural cause: three functions that need to operate in coordination are instead operating in silos. I call it the Implementation Risk Triad.

Enterprise implementations depend on three interlocking functions, each of which owns a critical domain:

• Legal / Contracts: led by the General Counsel, owns the contractual framework: risk allocation, scope definition, IP protection, and dispute provisions. The limitation is that contracts operate after the fact. They define remedies, not prevention. Without operational visibility into how the project is performing against contractual commitments, the GC is reviewing a document that no longer reflects reality.
• Enterprise Architecture / IT: led by the CIO or Chief Architect, owns the technical vision: vendor evaluation, solution design, integration strategy, and technical validation. The blind spot is that technical decisions routinely create contractual exposure that the architecture team doesn’t recognize. Without a legal and commercial context, the architecture team can’t flag when their technical choices are generating risk in someone else’s domain. 
• Portfolio / Program Management: led by the PMO or Program Executive, owns execution governance: milestone tracking, resource management, change control, and escalation. This is where success theater lives. Without both legal and architectural context, the PMO can’t distinguish real progress from activity that checks boxes without reducing risk.

Each of the five failure modes maps to a specific Triad breakdown. Contractual ambiguity arises when Legal drafts or reviews agreements without sufficient input from Architecture on what technical terms actually mean. Governance vacuums form when Program Management lacks decision-making authority, and no one has established the structure to provide it. Requirements drift takes hold when change control isn’t enforced, and no one monitors whether the delivered scope still matches the contracted scope. Integration blindness results from technical assumptions that go unvalidated until late in the project. Vendor capacity mismatch persists when no one assesses whether the delivery team has the depth to execute, and the contract contains no protections around key personnel. 

In every case, the risk was visible from at least one perspective. The failure occurred because that perspective wasn’t shared.

Operationalizing Shared Responsibility

The Triad is how the customer operationalizes its side of the shared responsibility with the vendor. When Legal, Architecture, and Program Management each manage their domains without a common operating picture, the customer can’t speak with one voice. Decisions stall. Requirements shift without documentation. Technical risks go unescalated. The vendor, whether performing well or poorly, is working against a customer organization that isn’t holding up its end. 

This is equally true in reverse. A vendor whose delivery team, contracts team, and project management function aren’t aligned creates the same dysfunction from the other side of the table. The Triad applies to both parties, but for the purposes of this article, the focus is on what the customer can control.

Making the Triad work requires three operational commitments:

• First, a shared reporting structure. All three functions need access to the same project information, not filtered through their own domain. That means a steering committee in which Legal, Architecture, and Program Management review the same data, ask cross-domain questions, and make joint decisions on risk. 
• Second, defined escalation triggers that go beyond the contractual escalation thresholds in the vendor agreement. When the architect identifies an integration risk, that information needs to reach Legal and the PMO the same week, not the same quarter. When the PMO identifies a schedule slip, Legal needs to assess the contractual implications before the vendor proposes a recovery plan.
• Third, regular cross-functional checkpoints. Not a quarterly review, but a recurring cadence, biweekly at minimum during active implementation, where the three functions assess project health together. The question at every checkpoint: are we on schedule, within scope, and meeting our obligations? 

What Good Looks Like

In addition to spending a decade analyzing failures, I have spent more than 30 years delivering enterprise implementations. I’ve led the projects that succeeded. I know what the room looks like when cross-functional governance is working, because I’ve been in that room. 

In the implementations that avoid disputes, the General Counsel doesn’t just review the contract and step away. The GC, or a senior legal representative with decision making authority, sits on the steering committee for the duration of the implementation. Not to manage the technology. To do what legal professionals are trained to do: monitor risk, assess whether obligations are being met, and flag when the operational reality diverges from the contractual framework. 

The enterprise architect does more than validate the technical design. The architect becomes a translator, converting technical risk into language that business and legal stakeholders can evaluate and act on. A vendor’s proposed integration approach carries more risk than the statement of work assumed; in a Triad-governed organization, the architect brings it to a steering committee meeting and explains the contractual and financial implications alongside the technical ones.

The third leg may be the hardest to get right, because it requires a cultural shift. The program management office reports what’s actually happening, not what the steering committee wants to hear. Success theater isn’t malicious; it’s the natural result of a PMO that’s evaluated on project momentum rather than project truth. Honest reporting means presenting a common operating picture that all three Triad functions evaluate jointly, including flagging when the vendor isn’t meeting resource commitments and when the customer’s own subject-matter experts aren’t available for testing.

One example has always stayed with me. A General Counsel at one of my organizations made it a practice to sit down with me regularly to review new master service agreements and statements of work. She never asked how we were going to deliver. That wasn’t her domain. Instead, she asked questions like: “What team is delivering that work?” “Do we know how to do that work?” And my favorite: “Do we have the capacity and capability right now to do that work?”

We did this almost weekly. The organization was actively growing and undergoing transformation, so new contracts were constantly being raised. She wasn’t checking our work. She was looking for uncertainty, for gaps, for risk. And because she asked those questions before the contracts were signed, we caught problems that would have become disputes if left unaddressed. 

That’s what the GC’s role in the Triad looks like in practice. Not managing the technology. Not second-guessing the architecture. Asking the questions that surface risk early enough to act on it.

The projects that avoid disputes aren’t the ones with the best technology or the biggest budgets. They’re the ones where someone bridged the gap between the legal framework, the technical architecture, and the project governance, early enough to matter.

What to Do Monday Morning

If you’re a General Counsel and your organization is in the middle of, or about to begin, an enterprise software implementation, here are three things you can do this week:

Request a project briefing. Not a status report, a briefing. Ask the CIO or the program executive to walk you through the current state of the implementation: what’s on track, what’s at risk, and what assumptions are driving the schedule. If they can’t answer those questions clearly, that tells you something.

Ask to see the governance charter. Every well-managed implementation has one. It defines the steering committee, decision rights, change control process, and escalation triggers. If one doesn’t exist, that’s a governance vacuum. If one exists but you’ve never seen it, that’s a blind spot.

Schedule a meeting with the enterprise architect. Not to learn the technology, but to learn the risk. Ask: where are the assumptions in this project that haven’t been validated? Where is the scope most likely to expand? What does the vendor’s statement of work assume about our environment that might not be accurate? Those are the questions that surface problems before they become disputes.