Many people seem surprised that a leading consultancy with a great track record like Accenture dropped the ball here. But I’m not.
. . .
The recent Hertz-Accenture lawsuit serves as a cautionary tale to companies on both sides of client-consultant relationships.
Rental car agency Hertz filed a $32 million lawsuit in April against consulting giant Accenture because it “failed to deliver the website and apps for which it was so generously paid.” Hertz pulled out of the contract in May 2018 after repeated delays prevented a launch originally scheduled for December 2017.
Hertz also claims Accenture failed to implement responsive web design, cited security risks due to poor coding, and alleged the design was too specific to the North American Hertz brand to be used for Dollar and Thrifty (brands Hertz owns and operates) as agreed upon.
Back in the day, people would say, “Nobody ever got fired for buying IBM.” That mindset probably applied here, too—Hertz figured Accenture was too big, too respected to possibly be a poor choice for a major project like this. Many people seem surprised that a leading consultancy with a great track record like Accenture dropped the ball here.
But I’m not.
But my guess is that Hertz and Accenture should share the blame.
That is most likely the case given what a monumental failure the project turned out to be—it can’t be any one party’s fault alone. Of course, this is almost purely speculation; I have no inside knowledge about the details of the project. But as the CEO of Tandem, a design and technology innovation firm that has taken on similar projects, I’d like to offer an educated guess of what I expect went wrong.
Hertz and Accenture didn’t nail down the requirements and communicate them across teams right from the beginning.
It’s fairly obvious Hertz didn’t have proper oversight on this project. That’s primarily its own fault, but also Accenture’s fault because every good consulting company makes sure its client has them under a microscope.
For example, when a project is meant to serve multiple tenants (brands, in this case—Hertz, Thrifty, and Dollar), that’s something you plan for from the outset of a project. It’s decided upon before you create any data models or begin on product architecture.
I’m not sure where the communication between Hertz and Accenture broke down here, as basic requirements gathering would have let Accenture know cross-brand functionality was a core component of the project. The same is true for the data protocols and responsive displays Hertz requested.
Accenture likely sent a business analysis team and a project manager to draft requirements, then relayed them to the development team. So much fidelity is lost during this handoff, leaving the delivery team with only a partial understanding of the client’s vision and expectations.
Additionally, although many of Hertz’s unmet demands were included in the contract, companies shouldn’t be baking their requirements and deliverables into contracts in the first place. Contracts live in a different world than the delivery teams. Even at Tandem, our teams aren’t going back to the contract. They learn about requirements from direct interaction and conversation with the client.
Accenture’s team was too big and (probably) siloed. And it’s obvious all the separate parts of this project simply didn’t come together in the right way.
Again, this is just conjecture, but I’d guess that the team working on this project was easily 60-plus people.
With a project and team of that size, you need incredibly comprehensive design and planning, the perfect project manager, and lots of product ownership protocols. Otherwise, communication between your payment processing team, your scheduling team, your logistics team, your front-end user experience team, etc. will break down and silo.
And I’d imagine Accenture outsourced some parts of the project to offshore companies, which only makes communication more difficult.
Once it came time to integrate all the separate parts of this project, Accenture likely struggled both with having all the necessary parts ready and effectively piecing them together.
Hertz probably rushed the timeline and requested a low budget—and Accenture played along.
For the project to have gotten so far overdue, and so far in the hole from a cost standpoint—it’s hard to fathom. This project had to have been doomed from the start by an unrealistic timeline and low-ball budget.
I’d imagine Accenture, a public company, was worried how investors would react if they told Hertz their requested timeline wasn’t doable and they lost the massive project to Deloitte or another competitor. It’s likely that someone at Accenture pushed back, but Hertz insisted. (As a side note, I often question whether professional services organizations should even be publicly traded for exactly this reason.)
With every massive project like this, things will go wrong and launch dates will be pushed back. But when you reach the point where you need an extra $10 million, that’s beyond the realm of what’s reasonable.
Here’s how we would have handled this project differently at Tandem:
We’d work with small teams.
Every software project has a “speed limit” that, if surpassed, will result in different work streams bumping into each other.
When explaining this concept, I like to use the analogy of painting a closet. You can paint a closet with two or three people, but not eight—at that point, everyone’s just crashing into each other and you get nothing done.
Some parts of projects are like painting a closet—include too many people on what should be a small team and nothing gets done due to friction.
We’d include our entire team, from designers to developers, in the initial drafting and design process.
When all teams are present for drafting, everyone can ask questions and gain a clear picture of what the end product should look like. This immersion process also entails job shadowing, interviews with stakeholders and customers, defining major themes and goals, and more.
We’d clearly lay out requirements outside of the contract.
My belief is that project requirements should not exist solely in a contract—not enough people see contracts at all, and not enough teams revisit contracts throughout the course of a project. For this reason, requirements should always exist somewhere else.
We’d have requested a longer timeline.
When you force a short timeline, as Hertz and Accenture did, disaster happens. There are only so many aspects to a project like this that you can develop in parallel.
We’ve worked on projects of a similar size at Tandem, and for the Hertz redesign, I would have proposed a two-and-a-half or three-year timeline (Hertz and Accenture landed on a year and a half).
Anyone who has worked in this industry long enough knows that when you rush a project, it only ends up taking longer due to miscommunication and problems with integration.
We’d have caught problems early on and accounted for them.
With software development projects, mistakes are inevitable. Changes will always need to be made. But you need to make sure to catch them early on and communicate them to the client, then push forward alongside them.
