With Friends Like These…. Uncovering Responsibility in Avon’s Rollout Failure

“Victory has many fathers. Defeat is an orphan”. 

                                          President John Fitzgerald Kennedy, on the Bay of Pigs Fiasco

It’s great line, and one that popular culture has changed to success has many fathers and failure is an orphan. JFK’s line is a stirring example of a leader taking ultimate responsibility for what happened under his watch. But the truth, which any student of the art of failure knows well, is that it takes as many people to kill an undertaking as it does to make it succeed.

So when I see headlines like InformationWeek’s “Avon Pulls Plug on $125 Million SAP Project”, my first reaction is to cringe at the obvious lack of knowledge about complex software implementations that went into that headline. Implementation projects always have many fathers and mothers, so to blame the software vendor for the failure is tantamount to blaming the grandparents for the misdeeds of their grandchild. They provided the DNA, no doubt, but someone else actually raised the little devil and loosed him on the world.

In the spirit of a truthier form of the truth, the headline should have read “Avon Pulls Plug on $125 Million Deloitte/IBM/SAP/Avon Project,” which properly distributes the blame for the failure, in probable order of culpability. Subsequent reporting on the story by IW has unearthed IBM’s role as the provider of the UI for the project, and some sleuthing on my part has dug up Deloitte’s role.

While Deloitte has declined to comment on their primary role in yet another enterprise software failure, and SAP and Avon haven’t publicly commented on who the SI was, I’m pretty confident my sources are right about the fact that Deloitte was the primary SI on the job.

As the primary SI, the headline could more succinctly read “Avon Pulls Plug on $125 Million Deloitte Project.” Of course, that might require Deloitte to take the high road and assume ultimate responsibility as the contractor in chief, in line with the spirit of JFK’s mea culpa as the Commander in Chief of a failed operation with hundreds of other “parents”. Not a likely scenario: as a snarky aside, one could be tempted to add the word “again” or “another” when talking about Deloitte and implementation failure in the same sentence. Deloitte, particularly when it comes to failures involving SAP software, is apparently a serial offender. More on this in a moment.

The reason I’m being so hard on Deloitte (and IW) is that it’s very clear that enterprise software projects have at least four “parents”, and in most cases each is contributing an essential component of the project’s DNA and each bears considerable responsibility for how well the project goes. The first three are readily identified: the software vendor, the SI, and the hardware vendor. Usually there are multiple vendors for each of these categories, in this case IBM Websphere built the front end UI and connectivity components, while SAP provided the ERP back office functionality. There are also several SIs involved in most large projects, though there is only one prime contractor among them.

The fourth parent is a little trickier to call out, as none of the other three really want to be accused of blaming the victim. But in the spirit of the truth, if you’re going assign responsibility for project failure, and of course project success, you’ve got to mention the customer as well. Sad but true – customers bear significant responsibility for project failure. Whether its Avon’s IT staff, or U.S. Dept. of Health and Human Services, a forensic analysis of project failure always finds fingerprints on the murder weapon that belong to the customer.

But there’s responsibility and then there’s ultimate responsibility, and with so many big vendors on contract to make this Avon project work – companies that collectively have thousands of successful implementations under their belts – it’s clear the real parental responsibility for this disaster comes from one of the vendor categories, not the customer side.

While not knowing the intimate details of the contract in question, it’s safe to assume that Deloitte was the primus inter pares in the deal. In a project with $125 million at stake, at a public company that pulls in $10 billion in revenues each year, and in the midst of a turnaround architected by a new CEO, most companies would engage in a project using an established global SI like Deloitte as the prime contractor. A global SI like Deloitte is precisely the company you want, apparently, to provide air cover when you go to your board for a $100 million project. Boards tend to think the Deloittes of the world won’t screw up this bad, and are willing to pay for the insurance policy that comes with using a major SI brand.

With board-level approval in hand, these global SI relationships typically extend deep into the C-suite and tend suck up most of the oxygen in the room – and the bulk of the project’s cost – especially relative to the revenues being paid to the enterprise software vendor. Indeed, in many of these large accounts, a company like Deloitte is easily earning ten times more revenues than any individual software vendor.

With that revenue differential comes a huge differential in influence, and therefore responsibility.

The prime contractor is the one that is supposed to manage the complexities of the project, mediate the different project needs and overcome the obstacles, bring all the different hardware and software products into harmonious union, and guarantee that when the project goes live, it meets certain basic criteria. FYI, a $100 million-plus write-down is not one of them.

If Deloitte was truly the prime, and there’s a lot of circumstantial evidence that it was, then the act of going live with a project that underperformed so dramatically – according to all reports – was Deloitte’s call. SAP provided the backend, and probably had some inkling that things might not be as copacetic as they should have been. IBM Websphere built the user experience, and would have had to definitely be aware that orders, inventory visibility, and a host of other problems were mucking up from the get-go. But the only player on the field with a full view of the action – or lack thereof – was Deloitte.

And if they were made of the same stuff as a JFK, they would have fallen on their sword with honor, instead of, as of this writing, trying to hide their parentage by not commenting.

This story of culpability in enterprise software is as old as the market segment, and the ability of the global SIs to make everyone but themselves look bad when the project flames out is impressive to the point of absurdity. What is also absurd is the pass they get from customers for this lack of culpability – but of course if project failures are only reported as software failures, how would the customers know what role the SIs play?

One of the bright shining hopes in the growth of cloud computing is the fact that the ability of big SIs to wreak havoc on customers’ implementations, to the detriment of their vendor “partners”, will wane as large swaths of what was once the SI’s bailiwick become subsumed in a standard cloud implementation model. Of course, that wouldn’t have saved Avon in this case. But with less of the implementation cost under the SI’s control, and less of the implementation success left up to a busload of junior programmers learning on the job, project failure may diminish.

Regardless, a little transparency is long overdue in the SI market. What really is Deloitte’s track record in enterprise software? Avon, the County of Marin, Los Angeles Unified School District, Levi-Strauss, the States of California and Florida – those are a few of the Deloitte failures that we know of. But it’s not easy to know about either failures or successes. Could it be that the risk of failure a la Deloitte outweighs the brand value of having Deloitte on your side? Shouldn’t a customer be able to judge the relative value of an SI based on some objective data about their ability to deliver on time and on budget?

And could a software vendor like SAP or IBM – or any other vendor dependent on global SIs as a channel – insulate itself from the negative drag that SI-driven project failure creates by insisting on some modicum of accountability from its SI partners, instead of being hung out to dry, as is the standard operating procedure of the SIs today?

Okay, when pigs fly, you say? One can dream, can’t one?

Finally, where does this leave our friends at IW? As an ex-journalist, I understand the maxim “if it bleeds it leads” as well as any, and I guess that SAP was an easy target (though where was IBM in the original report?) But this story, IMO, could have been even bloodier if the true story had been told. With just a little digging a reporter could have figured out that Deloitte, not SAP, was the primary culprit, and a headline along the lines of “Global SI Giant Deloitte Leaves Avon Calling…. for a $125 Million Write-Down” might have gotten more page hits. Maybe not, but at least it would have been more accurate than the headline they used. Better luck next time….

 

6 thoughts on “With Friends Like These…. Uncovering Responsibility in Avon’s Rollout Failure

  1. Joshua, thank you for writing this to bring clarity and truth to the story. I feel that as cloud services become more accepted and prevalent it can be to the software providers advantage to gain a stronger voice in implementations. The current SI/Partner model will change in the coming years and if a software provider is smart they will take the opportunity to use the cloud to the customers advantage to deliver a better implementation experience and hold SI’s/Partners more accountable.

  2. ERP growth has been fuelled through large SI vendor partnerships. Software manufacturers needed to scale and it is difficult to grow if you have to provide all implementation services. This has created perverse incentives because ERP customization and complexity is where the major SIs generate revenue. This makes it difficult for ERP vendors to significantly bake out much of the implementation overhead. And, the ERP vendors have baked-in deniability for failed projects. In this case, SAP is not part of the project governance structure.
    The truth is that the gap between needs and out-of-the-box functionality differs among markets for any ERP product like SAP. This is a contributor to public sector problems, but it’s not clear if it played a part here. If it did, SAP is under no obligation to update the software to meet Avon’s needs. It falls on the SI to customize.
    This ERP model is short sighted. ERP manufactures have lost touch with core market needs through arms-length relationships increasing product development overhead. Collaboration tools can be used to better determine feature needs.
    SIs who burden customers with complexity and overruns are losing huge lifetime customer value. Customization and lock-in can no longer be the ‘gift that goes on giving’ to SIs. Extortion as a software business model isn’t sustainable.
    And, ERP providers and SIs can’t stop public disclosure of failure – this reduces long-term revenue potential.
    Cloud has exposed this generally unmet need to implement with a minimum of customization.

  3. Pingback: The New Year in SAP-land: Selling Customer Success (Part I) | EAConsult

  4. Not to let Deloitte off the hook (as you correctly identify the firm as a serial offender) but I have also found that the client is always the “first” parent and tends to be even more responsible for SAP implementation than the SI in most cases. Clients tend to “license SAP software” rather than “implement an enabler to business process excellence”. Thus the accent around the implementation has more to do with stuffing software into a firm than blueprinting and adapting better ways of working. Note that all of Deloitte’s failures (as well as those of their competitors) are centered around business blueprint breakdowns in which a client has agreed during licensing to adopt inherent “best practices” but then, during blueprint, claims “that’s not how we do it here. In short, the client buyers don’t get that “adopt” strategy communicated to the client practitioners and the SI is left holding the over-budget bag.

  5. Pingback: Even without Larry, Oracle’s Problems Will Continue | EAConsult

  6. Pingback: Le Blueprint, C’est Moi: the Counter-Customization Revolution comes to SAP SuccessFactors | EAConsult

Leave a Reply

Your email address will not be published. Required fields are marked *