The Failure
In 2016, Hertz contracted with Accenture to redesign its online booking platform, a project that seemed straightforward for a global consulting firm. The initial contract was for approximately $32 million, with an expected delivery timeline of around two years.
Three years later, the project had produced no working website. Hertz filed a lawsuit alleging that Accenture had failed to deliver a functioning product despite years of work and tens of millions in payments. The lawsuit described a project plagued by missed deadlines, changing requirements, and fundamental disagreements about what was even being built.
The case was eventually settled confidentially, but the core problem remained: $32 million spent, no website delivered, and Hertz still needed to solve its original business problem.
The Structural Analysis
The Hertz/Accenture failure illustrates a common pattern in enterprise software projects: attempting to automate business processes that haven't been explicitly defined.
The Requirements Problem
According to court documents, Hertz changed requirements frequently throughout the project. But this "changing requirements" framing obscures the real issue: the requirements were never explicit in the first place. What changed wasn't the business need; it was Hertz's ability to articulate what they actually wanted.
Tacit Business Knowledge
Car rental is deceptively complex. A "simple" online booking must handle:
- Dynamic pricing across thousands of locations
- Insurance options that vary by state and country
- Corporate account rules and negotiated rates
- Loyalty program integration with multiple tiers
- Add-ons, upgrades, and cross-sells at checkout
- Integration with fleet management and availability systems
Much of this logic existed only in the heads of experienced Hertz employees and in legacy systems that had evolved over decades. It had never been documented in a way that could be translated into new software.
The Knowledge Gap
Requirements assumed to be explicit
Both parties assumed that "build us a new booking website" was a clear enough specification. It wasn't.
Business logic was tacit
How pricing worked, how exceptions were handled, how edge cases were resolved: this knowledge existed only in institutional memory.
Discovery treated as scope creep
When hidden complexity was uncovered, it was framed as "changing requirements" rather than the natural revelation of tacit knowledge.
No structural assessment
Nobody mapped the actual decision logic before estimating the project or signing contracts.
What Structural Assessment Would Have Revealed
A proper structural assessment before the project began would have identified:
Undefined Business Logic
Pricing rules, exception handling, and edge cases had never been documented. This work needed to happen before development.
Integration Complexity
The scope of backend integration required was far larger than either party initially understood.
True Project Scope
This wasn't a "website redesign." It was a business process re-engineering project with a website as an output.
Recommended Path
Complete business logic documentation phase before any development begins. Revise estimates after discovery.
The Lesson
The Hertz/Accenture failure wasn't about bad development or poor project management. It was about trying to automate processes that had never been explicitly defined. You cannot build software to implement business logic that exists only in people's heads.
The $32 million could have been saved by spending a fraction of that on structural assessment: mapping the actual decision logic before signing development contracts.