Skip to content

Thoughts on the Hertz – Accenture lawsuit

Let’s start with a disclaimer – I have no knowledge of this situation other than what I’ve read on the news. This post is conjecture and opinion, not fact!

There’s a news story about Hertz suing Accenture over the design and build of the new Hertz digital eco system. Many of the challenges sound horribly familiar – and there are lots of smart people commenting on Twitter. When reading the articles, two things really stood out for me.

Firstly, Hertz seems to have treated the engagement as a one-off project, and secondly, they outsourced pretty much the entire project to someone else. I think those two aspects of the project are fascinating.

Let’s start with treating the re-design of your platform as a project. I may be entirely wrong, but I assume that for Hertz (prospective) customers, the digital experience is key. If they are like most consumer brands, somewhere between 25 and 60 percent of their customers interact with them online during the purchase process. I’m guessing that a very large number of customers transact directly with Hertz using their web platform, and that those interactions are more profitable for Hertz than transactions via other channels – low cost to serve, no commissions, lots of cross-sell/up-sell. It’s also very likely that the role of the digital channels is growing in relative and absolute terms, and that key differentiation opportunities will come from digital. Oh, and their major competitors (on-demand services like Uber and Lyft) use digital as their main interaction channel.

So treating their digital platforms as a “project”, or even a series of projects, strikes me as wrong. The digital platform is a core aspect of the way they engage with customers, with no obvious end date, and a roadmap that evolves in the light of market conditions. It’s not a marketing campaign, with a big-bang go-live, or an SAP implementation, with an upfront project and ongoing maintenance – it’s a sequence of releases, each solving one or more problems for customers, the business, regulators, suppliers. It should be treated like a product or service in its own right, not just a customer acquisition channel.

This matters, because in most large companies, a customer acquisition channel is treated differently to a core service. Customer acquisition is a tactical process – invest in what works, reduce spend in what doesn’t, and most of the spend tends to be external – Facebook ads, marketing campaigns, media budgets. If you’re in charge of a customer acquisition channel, your key skill is to extract as much value as possible from your suppliers.

If you’re building a core service for the business, however, your outlook is very different – your time horizon tends to be years rather than months, and your core skills is defining and delivering the product roadmap. You typically assemble a range of skills, from a range of vendors, to do that, but the overall vision belongs to your team. Building that team’s capability is a huge part of your ongoing success.

The second aspect, bringing in an outside firm to deliver the new platform, is another worry. It’s never black and white – even if you have a big product team, you’re likely to face skill and capacity gaps, But outsourcing the whole thing – including product ownership – and relying on a contractual specification to get what you want, means success is determined by your procurement department’s ability to write a contract, and your upfront ability to specify requirements in a way that your vendor can’t dodge. And once the project is delivered, you remain dependent on your supplier – because you haven’t got the internal skills to evolve your platform.

The article suggests Hertz wrote a pretty comprehensive set of requirements, with forward-thinking deliverables like a design system, re-use across brands, and a “core component” library. But – in my experience – those deliverables don’t really add much value when the future rolls up. Test-driven development, Behaviour-driven development, continuous delivery – those really help. Those are things a vendor would often skip – they just want to deliver the project as cheaply as possible, get paid, and move onto maintenance and support (and also get paid).

Compare and contrast – a previous client (an airline) noticed that more and more customers were using mobile to buy tickets and check-in. They had an app, but it had not received a lot of investment, and the focus was primarily on cross-sell/up-sell. Customer satisfaction was terrible (the app didn’t work particularly well), and the team was heavily dependent on a supplier. Once they recognized that mobile check-in was the way their premium customers tended to interact, they set up an internal team to create a mobile product vision. They aligned on key value propositions, and assembled a team; my company provided a range of specialists in product management, design and development. We worked on a product roadmap, with lots of small-ish releases, a beta programme, and the gradual transition to an internal team.

And how about the money? The Accenture budget ran to $32 million. I know that sounds like a lot of money – but it’s not unusual for large-scale digital platforms to cost in that region. It’s (presumably) multi-market, multi-lingual, with transactions, payment management etc. But, let’s look at how you might spend that money in a universe where you care about developing internal skills. I’m going to take a 5 year period to spend that $32 million.

The following numbers are full of assumptions – but give an order of magnitude indication. If you have an annual budget of around $6 million to spend on a team, and the fully-loaded cost of a team member (designer, developer, product owner, QA, DevOps person) is around $200K/year, you can hire a permanent team of around 15 people. In year one, you probably want to bring in external folk , with skills you don’t have, and let’s assume their fully loaded cost is around $300K/year. So in year one, you probably have a team of 5 – 8 consultants, and 2 or 3 internal people; you change that balance over time.

So, can a team of 10 – 20 people deliver a whole new platform in 5 years? Yes, they can. Of course, their first release will be nothing like “a whole new platform”. It might feel disappointing – “we wanted a whole new platform, and all we got was a better sign-up form!”. But getting that feature out into the world, figuring out whether it delivers what you expected, and getting the next feature out shortly after – it’s a sustainable way of building software products. It gives you actual control (as opposed to the illusion of control which you get from project plans stretching over years).

Whilst the articles I’ve read suggest many things went wrong on the project, I think the biggest decisions organisations need to make are “is this core to our interaction with customers”, and “should we outsource this or build internal capability?”.

Post a Comment

Your email is never published nor shared. Required fields are marked *
*
*