It was widely reported last week that Hertz filed a lawsuit against the multi-national consulting and outsourcing firm Accenture, charging it with failing to deliver on a contract to provide a new website for the car rental giant and its various sub-brands.
The total cost of all Accenture’s works cited in the suit? An eye-watering $32,000,000. No, that’s not a typographical error, that’s really how much Hertz claims to have spent on getting its website built so far.
Must be a pretty fancy site, right? Well, don’t get carried away. Hertz claims it engaged Accenture to produce a device-agnostic, responsive website consisting of several components, none of which – it has to be said – seem especially novel. Hertz also alleges that it specified the build should utilise a common core of reusable libraries. The intention was to make it simple to support all of Hertz’s brands across all countries they operate in.
So far, so vanilla, but the suit asserts that Accenture simply ignored these (and a number of other) requirements and instead developed a website for just the North American business, with no thought given to reusable components and with code that was riddled with security and performance bugs.
Interestingly, Accenture (at the time of writing) seems willing to fight the lawsuit, so the situation may not be as clear-cut as Hertz has made out.
Either way, much of the reporting I’ve seen on this story has focused on the sheer cost of the works and made many excellent points suggesting that the business model of companies such as Accenture deliberately works to inflate fees once the client is already heavily committed. Beyond $7 million for the initial discovery work, the lawsuit doesn’t say what the agreed contract fee was, but it does detail how – once tied in – Hertz was continually billed by Accenture for fixes or new technology of dubious value.
What stands out to me, however, is the other aspect of this situation. How did the amount spent by Hertz balloon up to $32 million before a stop was called to the work?
This highlights to me the fundamental issue many businesses seem to encounter when embarking on large projects that are not within their own core competency – namely their engagement with the day to day running of the project. After all, it wasn’t until Hertz executive asked about progress on tablet views that the penny dropped that Accenture simply hadn’t done many of the things Hertz has asked of it.
I’ve read anecdotal evidence that prior to embarking on this project with Accenture, Hertz, in fact, fired much of its internal digital and developmental talent, handing over full control to Accenture. This, in my opinion, is its first (if not biggest) mistake.
I’m not going to re-tread the age-old path of ‘don’t outsource, do it in house’ because in a lot of cases outsourcing is appropriate. This is not a zero-sum game. If a company doesn’t have the right culture, talent, or scale to manage a project, they will need outside help. The key, though, is that a major project like this needs to be a partnership with active day-to-day engagement from the client. Hertz should have had its own internal talent involved to both help guide the project and to provide pro-active oversight, and that should have been that person or team’s primary job function at Hertz.
Including clients in an agile process in this way will give better outcomes on all sides. Not only can the client remain engaged and spot misunderstandings or other issues far, far earlier than would otherwise be possible, but the development team gain access to the domain knowledge that only the client possesses.
According to the lawsuit, in this case, this did not happen. So impressed was Hertz by the sales presentation that they decided to trust Accenture to also act as the Product Owner.
I strongly believe that client ownership is a – if not the – fundamental driver of successful digital projects. What’s more, the bigger the project the bigger the need for engagement. We’ve seen this time and again with big projects that are handed over to large consortiums where, I feel, lack of interaction with both client executives and end users is a large contributing factor in project failure and, more commonly, excessive cost overruns.
Another point worth raising is that if you are expecting to spend millions on a project, the chances are that the project will never end. I do not mean this in the sense that it will overrun on both time and cost, but that such a large project is likely important, and probably business critical – as it clearly is in this case.
As such it will need to be both supported and expanded over time to respond to the evolving needs of the business and the market, just like any traditional infrastructure, such as a factory, would. When the Hertz website was delivered, was Accenture planning to simply drop off the files and never be involved again? Unlikely. Somebody needs to maintain and continue to adapt and improve that system, so as a client, you’re hiring a long term partner on a continuing basis.
I don’t intend to shift all the blame onto Hertz; it has clearly been wronged. However, in my opinion, the company’s senior team were too trusting and didn’t give the project the attention it deserved. Project owners need both their own internal expertise, as well as that brought in by a partner. It’s only when these two pools of knowledge work together that you can plan an effective future roadmap, provide ongoing development services and constantly review your technical and strategic plans. This approach should be built into a relationship from day one.
Looked at from this perspective, it appears to me that the Hertz executives in charge simply didn’t understand that the website project would inevitably continue beyond the initial build. If they’d have recognized this, they would have understood that they required at least some talent on their side of the arrangement that was focused on the project full time. The company should never have let that talent go, as it allegedly did.
So, should Accenture shoulder all the blame here? In my humble opinion, no. Hertz put itself in an untenable position before anyone even typed a line of buggy code. I hope lessons have been learned, but I suspect we’ll continue to see similar stories.