Dissecting Disaster

Dec 21, 2010 2 Comments by

I read a great article on ZDNet which recapped lessons that organizations can learn from the recent SAP implementation disaster in Marin County, California.  I also listened in on a very good web seminar a while back on the same topic that was hosted by an ERP consulting company called Panorama.

A quick note before I start: I do not work with or for the folks at ZDNet or Panorama and I’m not receiving anything in exchange for mentioning them.  I just found their publicly-shared information useful for companies thinking of making a big ERP investment.

A little history for context: Like most organizations that take on an ERP project, Marin County, California sought to bring efficiencies and cost savings to their enterprise by leveraging SAP as their new, completely integrated business information system of record.  They did what they thought was a thorough package selection based on sound requirements and hired a big, reputable integration partner in Deloitte.

But by the time their project was finally halted, the County had spent over $30 Million without realizing anything close to their vision for efficiencies.  The County sued their integration partner for misrepresentation and sub-par consulting services while the integrator counter-sued for unpaid fees.

Take-Aways: Here are some of the lessons ZDNet & Panorama suggested we can learn from the disastrous Marin County SAP project:

1. Define and prioritize your functional business requirements before engaging with any vendors. Most ERP vendors are more than happy to show you all the things their products can do. However, chances are very good that you don’t need all of the bells and whistles – at least not right away. And no amount of sugar-coated extras will satisfy you if the new ERP fails to deliver your highest priority, core business requirements. It is common for ERP sales teams to inflate the expectations for their products, so be ready to establish clear priorities, research every detail and check references.

2. Set realistic expectations for scope, schedule and costs. Diligently manage these elements as the project unfolds by keeping the team focused on the project management “triple constraint” that balances these three factors.  The triple constraint suggests that you cannot change one of the three elements without impacting the other two and vise versa.

3. Know thyself. Potential ERP buyers need to take a long, hard look at their demonstrated  internal capacity to maintain and support an enterprise system like SAP. It takes a huge shift in skills – especially for IT and business process owners, not to mention system users.  It may be a recipe for disaster if you commit to implementing an ERP without the long-term lifting capacity to support it.

4. Emphasize constant communication across the project and up and down the stakeholder map from the executive team to the board to the employees and users.  Engage users, subject matter experts and business process owners at all levels before the project and during execution. Treat your ERP project as a business project as opposed to a technology project.  Don’t forget to gather feedback on how effective your communication is being.

5. Use an incremental implementation approach instead of a “big bang” to reduce risk and sort out system issues while limiting exposure. It’s considered a best practice to start with a portion of functional scope and introduce new features in later stages or start small with a subset of the organization before rolling things out in phases to the entire org chart.

6. Insist on less reliance on outside consultants and more accountability for decisions by internal staff who have a more vested interest in the organization’s needs. This is especially hard to do when the consultants seem to know all of the new tools better, but it is required as a part of knowledge transfer if you are going to be successful once the roll-out is complete and the consultants have moved on to their next gig.

7. Define clear success measures for the ERP project up-front and make sure the integration partner is vested in their attainment.  Plan to circle back at regular intervals and measure whether or not these goals will be achieved once the project is complete. Have frank conversations early in the planning process about what options might need to be considered in the case of a lack of progress.

8. ERP vendors should “walk their talk” and demonstrate their commitment to client success by tying a portion of their payments to client satisfaction and the measurable attainment of project goals. Buyers should insist that their vendors be willing to put this kind of “skin in the game”.

The lessons learned mentioned here are not new – and they have surprisingly little to do with what technology package an organization chooses.

-Steve

Questions for Chatter:

  1. Which of these ERP lessons do organizations seem to have a hardest time learning?

OBTW: here are some ways  for you to contact the webinar hosts for more information:

Change Agent Skills, Change Communication, Change Execution, Change Leadership, Stakeholder Readiness, Team Dynamics

About the author

I help people and teams succeed with big changes... never a dull moment!

2 Responses to “Dissecting Disaster”

  1. Jenni Doyle says:

    Oh…. how to pick just one! I’d have to say that in my experience, the one that organizations fail to evaluate is “Insist on less reliance on outside consultants”. I also think it’s one of the most important as neglecting to do this will cost the organization long-term. This is also not something that most consultants are going to advise you on as they benefit when this step is overlooked.

  2. Rudi Burkhard says:

    ERP implementations usually start in the wrong place. Not sure about the public sector, but businesses generally start with finance. That is the wrong place to start. An ERP system should be started in the supply chain – production and distribution – those areas that bring value to the company.

    I suspect it is no different in the public sector – their job is not finance it is to provide services – finance is important but secondary.

    However, businesses will continue to start with finance nevertheless.

    Rudi

Leave a Reply


Time limit is exhausted. Please reload CAPTCHA.