Recently, the Hertz car rental company sued Accenture for $32M in damages. The suit (pdf) alleges breach of contract in Accenture’s agreement to build and deliver a new website. This new site was supposed to:
- support the Hertz, Thrifty, and Dollar brands, starting with Hertz, North America
- be a ‘responsive’ site that works across phone, tablet, and desktop form factors
- work across the geographies in which Hertz operates
Sadly for everyone, the site never shipped to customers. Not one bit.
“We haven’t shipped” is like nails on a chalkboard to me, so this event got my attention.
Reading through the plainly-written suit, I feel like it’s safe to say (subject to accuracy of Hertz’ representation) that, this project ended up materializing the major risk factors for software delivery.
In The Economics of Software Quality, software quality expert (witness) Capers Jones’ demonstrates that:
- the primary driver of software delivery cost and risk is the size of the project.
- one of the main risks in software delivery is that the project will not deliver software that provides value at all or will do so late.
- low quality or inability to put a complete set in place of working functionality is one of the primary issues blocking delivery.
Effects of Project Size and Quality on Delivery describes those risk drivers and conclusions in more detail. Today, let’s analyze Hertz’s case using this framework.
Risk: Project Size
Here’s what Hertz wanted:
The primary objective of the project is to redefine the customer experience on Hertz’s digital platforms, by developing a market-leading website at Hertz.com and a complementary suite of mobile applications, all based on a platform that Hertz could readily extend to its other rental brands, including Dollar and Thrifty.
Ok, this is definitely going to be a large project. Additionally, the suit states that:
the Architecture Specifications for the Project expressly specified that a fundamental principle of the design of the website was its extensibility – that is, the use of a common core of libraries that could be extended across the websites and mobile apps for each of Hertz’s brands.
So the project is not delivering just three websites that need to work across multiple geographies (yes, seems like internationalization was included too), but it’s a platform for doing all of this.
The size of this project is large, and that’s the primary risk driver of software projects. My guess is that it’s in the 1,000 to 10,000 function point range of Jones’ charts indicating a probability of cancellation of 5%-45%, based on size alone.
This is also customer-facing so there is probably going to be pressure to ship by a certain date so that new features can provide additional revenue. i.e. there is likely non-trivial business revenue risk attached to this project in addition to the risk of tying up $32M of capital.
Since there’s a lot riding on this project for Hertz, let’s see what Accenture did to assure the quality of the delivered product.
Risk: Quality
Interestingly, Hertz also gave product ownership responsibilities to Accenture. So, from a certain perspective Accenture can argue that this software meets the requirements, because they define the requirements through product ownership. But if it doesn’t work at all, it’s kind of hard to say that (even if you’re willing to put ethics aside). The suit alleges:
Accenture failed to perform proper testing of the software that it developed. Accenture did not perform tests on many components of the system. When Accenture did perform tests, they were seriously inadequate, to the point of being misleading.
That’s pretty clear. What was delivered for testing didn’t actually work.
Later in the suit, Hertz claims that only the “happy path” worked on the site, and “deceptively” so. The lawsuit alleges that Accenture “had performed only selected tests, which tended to conceal Accenture’s deficient work.” Error handling, security, performance, and other matters were unhandled. So this project was firmly in the ‘low’ quality camp, which gives it a 15%-45% probability of cancellation.
Brace for impact. You know what’s coming.
Business impact
Despite having received tens of millions of dollars in fees, Accenture never delivered a usable website or mobile apps. To the contrary, simply completing the project – which required identifying and remediating the defects in Accenture’s work and the development of functionality that Accenture was supposed to deliver but could not – required Hertz to expend more than $10 million in additional fees. Worse, Accenture’s failure to timely deliver the website and apps for which it was so generously paid has caused Hertz to lose millions of dollars in revenue in a tremendously competitive industry.
As expected, the business risk of failing to deliver materialized:
- $32M initial investment plus $10M to fix
- “millions” of dollars in lost revenue in a tremendously competitive industry
Not only did Hertz cancel execution of the project, but they are now suing Accenture after being a customer for 15 years.
This all sounds pretty bad. However, apparently, Hertz was able to turn this initiative around by replacing Accenture with another vendor and that project succeeded.
Looking for the follow-up
Honestly, I’m looking for the follow-up. I have so many questions:
Objectives and Strategy
- Did Hertz pull product ownership back in house so that it had direct control over development focus? Did they at least write their own acceptance tests?
- How did the scope change? Was the project refocused to deliver the most essential portions that the Hertz business needed?
Processes
- Was the software delivery process changed to provide value to customers through frequent releases?
- What quality practices were incorporated baked-into the delivery pipeline? Do they now have an automated set of functional tests that indicate whether a new release is ready for testing and use by customers?
Basically, I’m wondering if Hertz and its partner adopted modern software delivery practices like continuous integration and continuous delivery on the second attempt. Continuous Integration and Delivery are designed to help the development team and project stakeholders manage project risk by helping the team build, deploy, and release software that meets a shared definition of acceptance criteria.
If you have a pointer to how Hertz succeeded on the second go around, please share it with me. I’d love to understand and share what went right.
#NoDrama
