The article by The Register regarding Hertz suing Accenture over their failed website revamp deal has gained a lot of attention on social media creating a lot of discussion around failed software projects and the IT consulting giants such as Accenture.
What I found saddest in the article is that the part about Accenture completely fumbling a huge website project doesn’t surprise me one bit: I stumble upon articles about large enterprise IT projects failing and going well over their budgets on a weekly basis. What was more striking about the article is that Hertz is suing Accenture, and going public with it. This tells us something about the state of the IT consulting business, and you don’t have to be an expert to tell that there is a huge flaw somewhere in the process of how large software projects are sold by consultancies, and especially how they are purchased and handled by their clients.
Just by reading through the article, one might think that the faults were made completely on Accenture’s side, but there is definitely more to it.Hertz too has clearly made a lot of mistakes during crucial phases of the project: in purchasing, service designing and development. I’ll try to bite into the most critical and prominent flaws.
If we dig into the actual lawsuit document we start getting a better picture of what actually went down, and what led to tens of millions of dollars going down the drain on a service that is unusable.
Reading through points 2. and 3. of the legal complaint we get a small glimpse into the initial service design process:
2. Hertz spent months planning the project. It assessed the current state of its ecommerce activities, defined the goals and strategy for its digital business, and developed a roadmap that would allow Hertz to realize its vision.
3. Hertz did not have the internal expertise or resources to execute such a massive undertaking; it needed to partner with a world-class technology services firm. After considering proposals from several top-tier candidates, Hertz narrowed the field of vendors to Accenture and one other.
Hertz first “planned the project, defined the goals and strategy and developed the roadmap”. Then after realising they “don’t have the internal expertise or resources”, they started looking for a vendor who could be able to carry out their vision.
This was the first large mistake. If the initial plan, goals and vision are done before the vendor, the party who is responsible for realising the vision, is involved, you will most likely end up in a ‘broken telephone’ situation where the vision and goals are not properly transferred from the initial planners and designers to the implementers.
This is a very dangerous starting situation. What makes it even worse is this:
6. Hertz relied on Accenture’s claimed expertise in implementing such a digital transformation. Accenture served as the overall project manager. Accenture gathered Hertz’s requirements and then developed a design to implement those requirements. Accenture served as the product owner, and Accenture, not Hertz, decided whether the design met Hertz’s requirements.
Hertz made Accenture the product owner, thus relieving the ownership of the service to Accenture. This, if something, tells us that Hertz did not have the required expertise and maturity to undertake this project in the first place. Making a consulting company, a company which has no deep insight into your specific domain, business & needs, the owner & main visionary of your service is usually not a good idea. Especially when you consider that it might not be in the interest of the consulting company to finish the project in the initial budget, but rather to extend the project to generate more sales and revenue.
Having the vendor as a product owner is not a rare occurrence, and it can sometimes work if the vendor has deep enough knowledge of the client’s organisation, business & domain. However, when working in such a large project and for a huge organisation like Hertz, it’s impossible for the consulting company to have the necessary insight and experience of Hertz’s business.
Moving on to the development phase of the project:
7. Accenture committed to delivering an updated, redesigned, and re-engineered website and mobile apps that were ready to “go-live” by December 2017.
8. Accenture began working on the execution phase of the project in August 2016 and it continued to work until its services were terminated in May 2018. During that time, Hertz paid Accenture more than $32 million in fees and expenses. Accenture never delivered a functional website or mobile app. Because Accenture failed to properly manage and perform the services, the go-live date was postponed twice, first until January 2018, and then until April 2018. By that point, Hertz no longer had any confidence that Accenture was capable of completing the project, and Hertz terminated Accenture.
Hertz finally lost its confidence into Accenture ~5 months after the initial planned go-live date, seemingly after at least a full year into kicking off the project partnership with them.
If it took Hertz around 1½ years to realise that Accenture can’t deliver, It’s safe to say that Hertz & Accenture have been both working in their own silos with minimal transparency into each other’s work, and critical information was not moving between the organisations. My best guess is that Hertz & Accenture met only once in a while to assess the status of the project and share. But a software project like this should be an ongoing collaborative process, with constant daily discussion between the parties. In a well functioning organisation, the client and vendor are one united team pushing the product out together.
The lack of communication infrastructure is a common problem in large scale software projects between a company and its vendor. It’s hard to say on whose responsibility it should be to organise the required tools, processes, meetings and environments to make sure that the necessary discussions are being had and that knowledge is shared. But often the consulting company is the one with a more modern take on communication, and they can provide the framework and tools for it much easier.
We get a deeper glimpse into the lack of transparency, especially regarding the technical side, when we go through points 36. — 42. of the legal complaint, e.g. number 40.:
40. Accenture’s Java code did not follow the Java standard, displayed poor logic, and was poorly written and difficult to maintain.
Right. Accenture’s code quality and technical competence was not on a satisfying level, and that is on Accenture, as they have been hired to be the technical experts in the project. But if Hertz would’ve had even one technical person working on the project, and they would have had visibility into the codebase, they could’ve caught this problem right from the first commit, instead of noticing it after over a year of Accenture delivering bad quality code. If you are buying software for tens of millions, you must have an in-house technical expert as part of the software development process, even if only as a spectator.
The lack of transparency and technical expertise combined with the lack of ownership/responsibility was ultimately the reason why Hertz managed to blow tens of millions USD, instead of just a couple. If Hertz would have had the technical know-how and had been more deeply involved in the work, they could’ve early on assessed that the way Accenture is doing things is flawed. Perhaps some people in Hertz saw that the situation was bad early on, but since the ownership of the product was on Accenture’s side, it must have been hard for those people to speak up as they saw the issues. This resulted in Accenture being allowed to do unsuitable work for over a year, until the initial ‘go-live’ date was way past and it was already too late.
There have been rumours of Hertz leadership firing the entire well-performing in-house software development talent, replacing it with off-shore workforce from IBM and making crony ‘golf course’ deals with Accenture in 2016. And the Hertz CIO securing a $7 million bonus for the short-term ‘savings’ made by those changes. I’d recommend taking these Hacker News comments with a grain of salt, but I wouldn’t be at all surprised if the allegations were more or less true.
These kinds of crony contracts are huge problem in the enterprise software industry in general, and the news we see about them are only the tip of the iceberg. But that is a subject for a whole other blog post.
It’s important to keep in mind that the lawsuit text doesn’t really tell us the whole truth: a lot of things must have happened during those years that we will never know off. However, it’s quite clear that some common mistakes that happen in consulting projects constantly happened here too, and that the ball was dropped by both parties involved.
It’s going to be interesting to see how the lawsuit plays out, as it will work as a real-life example to both consulting companies and their clients on what could happen when their expensive software projects go south.
For a company which is considering buying software, the most important learnings to take out of this mess are:
Also, one thing to note is that many companies who have had bad experiences with large enterprise consultancies have turned to the smaller, truly agile software consultancies instead of the giants like Accenture. Smaller companies are better at taking responsibility for their work, and they have the required motivation to actually deliver quality, as they appreciate the chance to tackle a large project. For a small company the impact of delivering a project well and keeping the client happy is much more important than it is for an already well established giant.
Hopefully by learning from history and the mistakes of others, we can avoid going through the hell that the people at Hertz had to!