How do we Propose to solve it?

If we define ERP failure as not getting what you want from the system you’re trying to implement, in the way you expected to get it – and we do – then we see that there are as many ways to fail at implementing ERP as there are possible expectations about it. The number of potential expectations is almost limitless: some are about how much it will cost and when it will be fully implemented; some are about what it will do, and how; some are about the performance of the system in technical terms, and some are about the system’s evolution as the company itself evolves over time.

But if the number of potential expectations about a new ERP system is almost limitless, the number of actual expectations about any given implementation most certainly is not. And of the actual expectations that real people are actually expecting, only some are what we might call critical expectations: expectations that if not fulfilled will self-evidently cause the implementation to be viewed as a failure.

Consider, for example, a specific expectation that I, as a Manager of Accounts Receivable, might entertain concerning the cash receipts process:
Expectation: I expect that the Cash Receipts Processor will enter, in this order:

Customer code
Check number
Check amount

List of invoices being paid
Amount to apply to each invoice

Now suppose three possible outcomes:

The system we’re implementing does not let me enter the customer code, but requires me to pick from a list of active customers.

In this case, my expectation is not met exactly, but I may even like the way the system works better than I would have liked the one I asked for.

The system we’re implementing requires the processor to also enter the check number and the ABA routing number of the bank it is drawn on.

In this case, the system I expected would have been easier to use than the one I got. But time is not so critical that an extra ten seconds per check is going to cause any real harm. I am annoyed, certainly, and my people are more annoyed than me. But it’s not like we can’t see the bigger picture if it’s explained to us – in other words, this disappointment doesn’t qualify as a failure, even a minor one.

For every invoice paid, the system we’re implementing requires me to enter Customer Code, Check Number, Check Amount, Invoice Number and Amount to Apply, from scratch.

But it turns out that I’m in a business where every check pays off 62.7 separate invoices (say, freight, or retail auto parts). This clumsy method of entry would force us to hire three new Cash Receipts Processors just to keep up with our current volume of business – unacceptable!

Now, consider three different ways that my company might discover (and deal with) this shortcoming in the new system:

We discover it during negotiations for implementation services, and insist that it be fixed before the system is delivered. After some back and forth, we agree on a price, and the requirement for the change makes it into the implementation contract.

We discover it during acceptance testing, and become embroiled in a nasty argument. The implementers scream “scope creep!” We scream back that we expected a system that works. In the end, we compromise, which means we pay $5,000 we didn’t expect to pay and, worse, the schedule slips two weeks. Yes, this puts us into the 68% “challenged” category, but some people would say we got off lightly.

We discover it at go-live. Since nobody is going to stop a whole ERP implementation for something like this, we cram three more desks into Accounting, put three more workstations on them and resign ourselves to a needless $200K or so annual increase in payroll. So yes, now we have an official failure on our hands, by anybody’s definition.

It is clear that no system as complex as ERP will ever meet all of our critical expectations unless somebody is working to make that happen. It is also clear that there is a serious penalty to be paid for every day that the project appears to go forward while critical expectations remain unexpressed.
When we put it like this, it seems obvious that the entire ERP project team should be focused on the critical expectations that must be met if failure is to be avoided. It seems obvious that the team should concentrate on these critical expectations to the exclusion of almost everything else. It seems obvious, above all, that the degree to which critical expectations are being fulfilled should be the measure of performance for the project as a whole and for every team working in it.

These things seem so obvious, in fact, that most people are quite surprised to learn that they are almost never true. The reason for this is as astonishing as the fact itself: usually the critical expectations simply are not elicited from the people who hold them – that is, the people who will eventually decide whether the system is a success or a failure. Not being elicited, they are not written down. Not being written down, they are not shared with the internal project team or the outside vendors. And not being shared with anybody, they are useless for the critical purposes of risk management and performance measurement.

And why does that happen? That happens because most ERP projects start way too late. They start long after critical expectations should have been elicited and restated as requirements. Because the actual but unexpressed expectations that will determine success or failure won’t even be known until the project is either complete or dead in its tracks, the project team works toward other goals and measures its own performance using other criteria. With luck, these other goals and criteria won’t be too far from those the user company would have chosen for itself, if only it had known that it really needed to do that.

How do we propose to solve the problem of ERP failure? By eliciting the critical expectations that will determine success or failure from the key people who harbor them, by documenting these expectations as system requirements in unambiguous business language and by imposing these requirements on all parties participating in the implementation, especially system providers and consultants – all before the usual point that ERP projects are deemed to begin.