Doing Everything Wrong With ERP

If a graduate business school at a major university ever wants to write a case study on how not to do ERP, they need look no further than U.S. National Grid Co.’s series of decisions surrounding its buying, implementing and launching an SAP program for its power generating and distribution operation. It did nearly everything wrong.

As a result, now National Grid is embroiled in a massive billion-dollar lawsuit against its implementer that it isn’t likely to win.

For everyone else, the causes behind the National Grid action against Wipro – its implementer – should reinforce what I have written about in previous blogs and discussed at conferences on the steps needed to avoid what I call an “ERP train wreck.”

Analogy

After a train wreck, investigators often find that there wasn’t just one cause that led to the disaster but rather a number of errors and misjudgments that combined to contribute to the accident. This is exactly what seems to have happened with National Grid’s ERP project.

An independent audit conducted in the aftermath of the “blow up” revealed a significant number of issues that led to massive cost overruns, a rushed launch date and a useless system. The criticism laid blame all around the project, including:

  • An overly-ambitious design underestimated the scale of the cultural and operational transformation needed to make the ERP software system deliver on its promise.
  • Using multiple partners – some of whom were retained after the project was underway and replaced initial contractors – to design, build, implement and operate the system made it all but impossible for the ERP project to deliver on the promised benefits.
  • Because Northern Grid’s executives and management were focused on restoring power to customers following Hurricane Sandy, not enough attention was paid to what was happening with the system when it was activated during the clean-up operation.
  • Pre-launch testing was less effective then it should have been because not enough different types of scenarios were explored.
  • Launching the system was way behind schedule so pressure to “Go” got priority over ensuring the quality of the system and its functionality.
  • No one at Northern Grid took ownership of the project, especially regarding some of the business processes, and data being moved over from a legacy system was inadequate to allow the new system to meet the company’s needs.
  • The consultants overseeing the project may not have been vigilant enough in supervising the developers and implementers.
  • Staff training was woefully inadequate.

As a result of the snowballing problems, National Grid’s payroll was a disaster that cost $18-million to fix, more than 15,000 vendor invoices piled up that couldn’t be processed, inventory was a mess, and the company’s financial reporting went from needing just six days to 45 days which resulted in the business losing access to short-term borrowing facilities.

Blame for All

While a court sorts through the facts in the case and decides what to do about a raft of pre-trial motions and countermotions, one thing is obvious to me as a seasoned ERP system contract negotiator and drafter as well as an ERP litigator: What could go wrong in the National Grid ERP project did go wrong.

Murphy’s Law was alive and well and living at National Grid.

A lot of the problems, from cost overruns to delayed timelines and finger-pointing, could have been avoided up-front with a tightly drawn contract that laid out specific responsibilities. I haven’t read all of the documents in the National Grid-Wipro battle royal but I’ve been involved in enough of these cases to be able to surmise that one party or another needed to be much more detailed about what would be delivered and when, and how it would operate.

If nothing else, by the time the National Grid-Wipro dispute is concluded one way or another it will be an object lesson in what companies should not do when launching an initial or upgraded ERP software system.