How to Avoid a $32 Million Flop: Inside the Hertz-Accenture Lawsuit

Last week, Hertz sued former marketing partner Accenture LLP for failing to deliver a promised redesign of their website and mobile apps. While the complaint is still in dispute, companies can learn from what we know about this alleged breach of contract. Where does a big project like this go so wrong it ends up in a legal battle? How is it remotely possible to spend $32 million without getting a functional website or mobile app? And how can other companies make sure they avoid a similar disaster?

Here are just a few recommendations, based on years of my own professional experience as well as research conducted during the process of co-authoring a forthcoming book titled The Product Mindset: Succeed in the Digital Economy by Changing the Way Your Organization Thinks.

According to the complaint, Accenture took on the redesign of Hertz’s website and mobile apps all at once. Starting big like this is risky and often ends up being more expensive in the long run for both the client and the developer. If you start small and tackle one project at a time, you have a better chance at success. In The Product Mindset, we call this minimizing time to value.

Consider Harris Teeter. I’ve been using ExpressLane online shopping service for a while now and I’ve seen it evolve a lot since its inception. At first, a customer could only order through the website. It was only after some time that ordering capabilities became available on a mobile app. Since then, Harris Teeter has made small, incremental improvements on this app as they have adjusted to different customer, market and technology needs. This allows them to be competitive in a market that serves at least a quarter of Americans.

A smaller, gradual approach minimizes waste and maximizes learning. You can have the world’s best team of engineers, designers and coders, but value only exists when your customer can touch, test and deliver feedback about your product. If a company spends its entire budget and places all its expectations on a big launch, it won’t have the resources to make tweaks to the product.

The Hertz complaint alleges that Accenture did not deliver a product of value – the code quality was low, and there were “serious security vulnerabilities.” Hertz also notes that much of the testing that was performed was “happy path” testing, meaning only testing what happens when the customer does everything right.

These criticisms call to mind the disastrous launch of HealthCare.gov and the issues that came from not testing the site along the way. There was no “end-to-end testing” of its full implementation. And the exchanges for all 50 states opened on the same day, instead of a few states at a time.

Testing should be done on a variety of different devices, in a variety of scenarios and from different locations. Hertz complained Accenture didn’t create a responsive design that worked with tablets. The testing plan should have included all form factors so Hertz knew exactly what they were getting. When we worked with a major financial services company, we ensured that the stakeholders had a test version of the app on their phone to enable them to show it to their colleagues. It helped them have a smooth launch and win a lot of internal support.

Product developers should be testing continuously during development and showing the client their progress. Continuous testing – with inevitable modifications – is how you avoid unwelcome surprises come launch time.

While it is not clear whether Accenture engaged in customer testing or prototyping, this is one of the most important parts of software product development. A lot of money can be lost if customers can’t use the product, or worse – if they don’t see the value in even trying it.

The complaint states “Accenture served as the product owner, and Accenture, not Hertz decided whether the design met Hertz’s requirements.” How could Accenture make those calls without customer involvement? Additionally, I would not recommend a client completely delegate decision making to an outside partner. In my experience, the best decisions come from bringing together the customer’s voice, the client’s knowledge of their business and our product expertise.

Fast, flexible, and focused customer research should be one of the first steps of the process. Companies have to solve for need. They need to have done enough research that they already know customers will choose to pay for what is being built.

Take personal finance giant Intuit. Through their research, they noticed that a growing number of customers were involved in the gig economy. They uncovered a new need in the market – these customers needed an easy way to capture tax write-offs – and that’s how QuickBooks Self-Employed was born.

Research and testing with customers shouldn’t end. We need to be on the lookout for emerging trends and make sure that when we adjust a design because of technical constraints, it still works.

The Hertz complaint notes that one of the primary reasons for the delays was “Accenture’s difficulty in developing the ‘integration layer’ – which allowed the customer-facing Front-End Development code to communicate with Hertz’s back-end systems” for making and changing reservations and managing rewards.

I’m not surprised by this. A lot of people, when they build a mobile app, are caught off guard by the amount of work needed in integration. They only see the interactive layer – not all the work underneath it that makes everything else happen. They think tweaking the design won’t mean back-end changes, but it almost always does, and dealing with all the tradeoffs is tough.

This is one important reason why taking a smaller approach to product development makes sense. Developers need time to learn how to go “end-to-end” with these tricky systems.

In its complaint, Hertz said they requested a website and mobile applications that were “extensible to multiple brands and markets,” including their Dollar and Thrifty brands. This request makes sense for a client – extensibility can save the client money in the long run.

But overdoing extensibility can be tricky. It can be expensive and time consuming to build something that will cover every use case, and this time could lead to lost revenue. Moreover, forcing too much consistency between multiple brands can make the product less able to serve the needs of its unique audience.

At 3Pillar, we often recommend that brands who desire extensibility think about the most important elements – what needs to be completely consistent versus what is configurable. This allows for custom features unique to each brand that serve the specific needs of the brand.

Ultimately, if both a client and a developer are on the same page about these fundamental principles, they can avoid the miscommunications and failures that end with both of them losing money, time and a valuable relationship.