Lessons from an ERP Project Failure and Vendor Law Suit

A customer/vendor conflict: 

In a recent Computerworld article, Chris Kanaracus explains how Epicor Sued Over Alleged ERP Project Failure.  In the article, the customer attributes the project failure due to shortcomings in Epicor software.  Customer states, "The project did not go well due to a variety of shortcomings in Epicor's software."

Here is my analysis:

In my experience doing these sorts of procurements, when specific business requirements are defined well and included in the RFP, SOW, and contractual documents, then many project risks (both cost and schedule types) are shifted to the vendor. If the vendor agrees to meet a specific requirement and both customer and vendor sign the contract, then vendor is on the hook. However, if the requirement is not documented in the initial contract, then the vendor may later push back by describing the requirement as "out of scope" and will only do the work if they can bill the hours. Scope creep is not only common in ERP projects, it is actually a well-accepted fact.

As a casual reader of the article, I must state up front that I don't have all the facts in this story.  I only know what I read in the article.   So, based on the article and past experiences I can go out on a limb and suggest two things that might have happened:

1. The customer failed to specify the steps of a key process and include those details in their contract with Epicor.  Therefore, the process became ambigious and unclear.
2. Epicor team attempted to remedy a technical shortcoming through additional pro services (billable time), and they failed to reach customer satisfaction before the bill got to be a million bucks.

Lessons to be learned:

This article reminds us of some key lessons that we can use when working with vendors.

• Invest as much time as necessary into defining processes well.
• Identify specifics even if they are obvious or assumed.
• Include specific business requirements, solution requirements, use cases, story board, and other illustrations in the vendor contractual document.
• Group related requirements into "categories" and seek fixed pricing estimate for each category (this forces vendor to do more careful estimates and makes the project easier to manage).
• Create a project completion checklist up front (should map closely to the categories) and include that the contracts.
• Realize even if you defined requirements really well, you still might miss important ones.  Therefore, remember to buffer the project budget to cover requirements that may have been missed.

A fixed bid estimate may cost up to 25%-40% more than a standard estimate, but that is a significant discount over the 500%-1000% overrun that is not only possible, but likely if the requirements are not clearly spelled out and the work begins.

References

Kanaracus, C. (August, 2011). Epicor sued over alleged ERP project failure. Retrieved October 20, 2011 from http://www.computerworld.com/s/article/9219127/Epicor_sued_over_alleged_ERP_project_failure?taxonomyId=144&pageNumber=1.