Step 1: Hertz finds it does not have the internal digital/tech capabilities.

But rather than try to build that capability internally, it sought a "a world-class technology services firm" narrowing to Accenture and one other.

Ruh roh.
Oh no.

"After Accenture put on an impressive, one-day presentation for the Hertz team that included a demonstration of the transformed Hertz digital experience..."

So it would seem that it evaluated based on a design presentation. Not sure how much vetting of delivery was done.
Hertz saw they did not have the internal capabilities in tech and digital experience, so they went to a vendor.

But they also made that vendor the "product owner". Seems like a pretty critical misstep.

If you build ONE internal capability, product ownership is a good one.
Accenture committed to a "go-live" date with Hertz.

A functional web site or mobile app was never delivered.

Let me argue this is both parties' mistake: if you're building up to a massive go-live ("Big Bang launch") for 100% of users, this outcome becomes far more likely.
What's an alternative Hertz could have chosen?

A phased approach, slowly changing over parts of the customer experience and getting feedback as they went.

Start with the simplest transactions, and for users not doing those, just send them to the (still live) old system.
Hrm, okay, yeah I don't know what to say here.

If Accenture built a smartphone-responsive and desktop-responsive site, then wanted hundreds of thousands more dollars for a TABLET-responsive layout, "world class" may not the best label for their capabilities.
This one I quibble a bit more with. Hertz wanted an extensible design to be used across all its brands.

Sure, this is doable, but the best approach here is probably starting with 1 brand, getting it live, then refactoring to make it extensible.

(Again, though, never went live.)
Two minor comments here:

1. I'm VERY interested to know how the front end code created (a) security and (b) performance problems. cc @slightlylate

2. "FED code" = the front end. That's a new one for me! (Please do not re-use this phrase, very potentially confusing.)
Ooo, what's "misleading" testing??

Fun fact for Hertz and others. There's a thing called Test Driven Development (TDD) where the tests are written first! You might consider insisting on that, and also looking into Behavior Driven Development (similar, but for capabilities).
Yeah, you spent tens of millions of dollars and Accenture never delivered a functional web site. Then it cost you more millions to fix it.

That sucks. But, my dear friend Hertz, you should look at what brought you to these requirements, this vendor, and this approach!
Ah, not all that surprisingly, Accenture had trouble doing a systems integration with Hertz' technology.

The FED code [1] could not be hooked up to the backend.

[1] Don't call it that.
OH NOW WE'RE TALKING. It was Angular 2! They built it in Angular 2!!

“Front End Technology (Angular2) has been a challenge for us to deliver.”
Ah yes, the firm they brought in to clean up just straight up threw away Accenture's Angular code.
Hertz states that Accenture just wrote bad Java code.
Hertz says that Accenture told them to buy a license for a piece of software to build the CMS. Then, Hertz says, Accenture couldn't get that piece of software to work right.
Oh, huh, this is interesting. I wonder if this was a shake-up, or if they realized the project was a loss and didn't want to spend down staff time that could be billable elsewhere.
Ah, interesting! Hertz claims that Accenture only wrote "happy path" tests.
And that's it!

As a reminder, these are all claims made by Hertz in a lawsuit, and neither I nor anyone else not involved in the project can make any statements as to their validity.

But in a world where there are so many big failed IT projects, reading such lawsuits is useful.
If I were Hertz—or trying to learn from their experience—I'd take away a few lessons:

1. Build (don't buy) digital capabilities if you can
2. If not, at least build a product ownership capability
3. Insist on phased delivery: really-deployed websites used by real end users

...
4. Think harder about how you evaluate vendors, and probably also look more carefully at actual prior projects done by them; also please weigh references and past work more than flashy presentations
This right here my friends. If you're worried you can't hire top talent, think more deeply about what that means about the scope of work you'd be giving them in a "digital transformation" project. https://twitter.com/jeremybowers/status/1121185039629340672
This is another good point: people constantly complain about large govt IT projects that go in this way, but my experience is that this is really about "large and long-lived organizations" across sectors.

Govt just happens to be at scale and long-lived. https://twitter.com/slightlylate/status/1121211141936406529
https://twitter.com/keithkurson/status/1121210545724461057
Well, crap. https://twitter.com/simonw/status/1122140798164721665

This does help us understand this better, though. It means there's something in the incentives or mental models of C-level leadership here that is at the root, rather than ignorance of options.

As a systems problem, it's quite interesting!
Epilogue: https://twitter.com/businessinsider/status/1263957598035902465
You can follow @allafarce.
Tip: mention @twtextapp on a Twitter thread with the keyword “unroll” to get a link to it.

Latest Threads Unrolled: