Avon to SAP: We can’t put enough lipstick on this pig! – A failure in program risk management


Injured Piggie BankOn December 9th in a regulatory filing,  Avon announced that they were writing off $125 million in software and development charges related to the rollout of their business transformation program SMT (Service Model Transformation).   In the filing the company stated “SMT was piloted in Canada, causing significant business disruption in that market, and did not show a clear return on investment. This decision to halt the further roll-out of SMT was made in light of the potential risk of further disruption.”

The business scope of the IT project included campaign management, order capture, order fulfillment, field management and finance. Based upon our research, the technology utilized to enable the business transformation was comprised of SAP ECC 6.0 and CRM 7.0 including the Customer Interaction Center.  ECC powered the order to cash process for Avon’s Global Core Service Model, along with Vistex for pricing and promotions.  IBM’s WebSphere was used to build the user interface that would be used by  6 million representatives globally.

The short term economics of this decision make perfect sense.  If there has already been $125M invested in software and capitalized labor that is now a viable asset of the company, then the financial depreciation of this asset was probably set to begin soon.   Figuring a depreciation cycle of 7 years and a rough approximation of the license maintenance payments that Avon would have had to pay, the substantial hit to this fiscal year will improve earnings per share next year by 5-7 cents.    While that seems like a small number, consider that total earnings per share through three quarters of this year are less than 5 cents.   These calculations exclude the savings associated with hundreds of project team members that are also being cut lose as a result of the decision.

The comments from the Avon CEO and the spokesman from SAP point to some backroom dealings prior to the release of information from Avon.  SAP and Avon both state that the technology was not the issue, but rather the inability of the workforce to adapt to change.   Contrast this with the comment posted on Information Week’s article   from one of the top sales people in Canada that stated, “The website and programming produced so many errors it was impossible to tackle what should have been a simple task of placing orders and registering new representatives”.  The rep continued with her post saying “I lost over half my sales force, along with all the other leaders in Canada, as we watched the program they had named Promise annihilate our business”.  It is my belief that SAP conceded on some relief of maintenance payments and licenses to avoid being dragged around by the hair by the CEO.

Could this all have been avoided?  Perhaps, but the deck was really stacked against the project team.  Consider:

  • The leadership of the company and the transformation effort were replaced in the last 12 months.  This program was likely becoming the yoke around their necks and not the enabler they had hoped for.
  • The company had already struggled to implement Oracle App in its Brazilian operations and had to deal with the same kinds of representative attrition with a buggy implementation.
  • The representatives that sell the Avon product line are not your typical users that can be told what to do.  These are all mostly part time folks that need to pay for their materials and supplies.  Waiting on a help line for 60 minutes to place a simple order is bound to get them to walk.
  • Any program that takes 4 years to get out its first deployment is too large.  There is no way that it should take 4 years to discover that a system is not usable.

With 4 years to the first deployment, I have a strong suspicion that the CIO was under tremendous pressure, and the decision to go live did not come easy.  In this situation, the pressure on project schedule and budget blinded the program leadership to the risks associated with operational integrity and the ability to achieve the business case.   In our blog series on risk management, we identified this as one of the primary reasons that project risk management processes fail.

Leaders that are responsible for business transformation programs need to secure the program risk management processes and secure independent un-bias views of risk as a means of bullet proofing there implementations.

If you would like to learn more about how UpperEdge has helped companies assess and avoid large IT transformation project risks, or if you have any questions or comments, please do not hesitate to contact jbelden@upperedge.com.

Leave a Comment

*