The root cause of ALL failed ERP projects: The devils in the details

When companies want to replace an outdated ERP system, there is a lot at stake. These are high-risk projects that regularly fail. You might hear about those that end up in court, but you don't hear about others because people don't like talking about their failures, which is why buyers don't appreciate the difficulty of replacing an ERP system.

The root cause of all ERP failures is new software that doesn't meet expectations. Why does this happen? The answer lies in how the requirements are defined. Software buyers can't blame vendors if poorly worded or unstated requirements are not met!

When a salesperson responds to an RFP, if there is any way their software can meet a poorly worded requirement, they will claim "Fully meets," and a buyer can't say they are wrong.

Take a company with a large field sales team that is replacing an outdated ERP system. They wanted expense management functionality in their new ERP and specified the requirement as "Expense management & reimbursement." They were thinking of products like Concur and Expensify that allow a user to take a photo of a receipt but neglected to specify that detail level. The ERP vendor they selected had responded "Fully meets" on the RFP, but as far as the buyer was concerned, the ERP expense management module was so weak it was useless.

The devil in the ERP details

The real problems are the devils in the details. Those devils are the assumptions buyers make about the software that turn out to be false. And when this happens, expectations are not met. When you hear users say, "What do you mean the new ERP doesn't…" you know that a detail devil has been found. The more frequently this happens, the greater the buyer's remorse. Too many unmet expectations might mean the ERP never goes into production and is an outright failure leaving only a smoking crater in the budget. But it can get worse. A few months ago, a banker in my network said that two of his clients had been driven into bankruptcy by failed ERP projects.

You will find many ERP selection consultants who say something like, "You don't need to go into all that detail for a new ERP. Trust us. We have the experience to help you." But as the example above shows, this lack of detail leads to dissatisfied buyers. Part of the problem is you must specify requirements in sufficient detail, but writing those requirements is far too much work. That is why you need consultants like Wayferry who have a library of professionally written requirements they can use on your project. You still need to prioritize those requirements by weighting them for importance, but you have avoided the time and work needed to write them in the first place.

The key to meeting expectations is managing those expectations. If you specify your requirements in sufficient detail, and the vendor you selected responded accurately to your RFP, the RFP response DEFINES your expectations. It doesn't mean you will get everything you want, but it does mean you know what compromise you are making BEFORE you sign the contracts. When buyers find out after signing contracts that the software doesn't do something, that is when the buyer's remorse sets in.