How To Survive The Journey of ERP Implementation At Your Business

So you want to implement an ERP system. As a manager you should be aware that ERP projects are uniquely difficult to control.

Why is this and what can you do about it?

Let’s take a typical situation. Bob contracts with an ERP consulting company to implement an ERP system for his company. An ERP software package is chosen from a major vendor. Bob’s company has some unique system requirements, so customization is required.

The consultant estimates that it will take 16 months to implement the system. Panorama Consulting has released the 2016 Report on ERP Systems and Enterprise Software , and it says that 16 months is the average time for ERP implementation.

Bob checks the references of the consulting company and concludes they have a good reputation. He contacts other users of the software package and finds that the software is deemed adequate, although no one is head over heels in love with it.

The cost of an ERP system is usually around $10,000 an employee. It’s a
rough rule of thumb, but Bob’s 50-person company is probably going to
end up paying around $500,000 if things go as planned. Another cost estimate comes from the 2016 Panorama report referenced above, which puts the average cost at 6.5% of annual revenue. Assuming Bob’s company is generating around $6M/year in revenue, that would put the cost at around $400,000.

Unfortunately, as the Panorama report points out, there is about a 43% chance that the project will end in failure or in a state where no one is sure whether it was a success or not. In other words, ERP implementation is a very high-risk project.

Over 16 months a lot can change. First there are changes to the company’s business. Some changes, such as regulatory ones, cannot be ignored or postponed, so the project can be forced to include new features and change other features in the middle of the implementation. This has severe impacts on the schedule and cost. In software, once an architecture has been adopted and implementation started, changes tend to break the model and create the need for entire re-writes or for implementing hacker-like fixes (called kludges in the industry). These fixes do work, but create difficulties for subsequent programming. All of this results in increased time and budget.

As well as changes to the spec, over 16 months the project team will very likely change. Inside the consulting company there is inevitable churn of employees, and with resultant promotions and shuffling of employees, the consultant’s project teams are impacted.

It can mean that the project team working on the system at the later stages is totally different from the one that started it.

Some consultants play a bait and switch game by offering up an A class team when the contract is being negotiated, and later replacing it with a B or even C class team when they need the A team for another marketing effort.

The problem for Bob is, how does he manage all of this?

He has no way of really evaluating any new members of the project team and has to take the consultant’s word for their competence. As months go by, the project team is hard at work, but Bob cannot tell if the progress is as reported. There usually isn’t anything to see until the system is more or less complete and testing can start.

Finally, more than a year later, he gets some software he can evaluate. If at
this point it isn’t satisfactory what options does he have?

He has been paying progress payments for all these months at high consultant rates. If he is dissatisfied now and kills the project that will all be money down the drain.

That’s not much of an option, so typically managers try to get things back on track. Bob can fire the consultants and turn their work over to others.
These new consultants might be able to pick it up and finish it, but they are working with code they didn’t write and is almost certainly undocumented. Most of the time, project teams that take over a project will recommend a total rewrite or at least a major overhaul. This could double the original cost.

One thing you realize here is that Bob has tried to be as responsible as he
can, but despite all of his efforts the project can run off the rails and be a total disaster.

It’s a nasty situation for any manager.

So what is the answer?

In my opinion the thing that makes these projects so hard to manage is the
time they take. The more than a year of paying the consultant before he sees anything forces Bob to have a huge sunk cost before he can even
evaluate what he is getting.

So the best advice I can give to control ERP implementation is to do everything possible to reduce the project time. Either find a package that you can live with, with either no customization or a minor amount, or look at vendors who have offerings that can produce a system in a very short time.

There are many vendors who feature fast implementation. To mention just a few: Netsuite claims implementations in 6 weeks, Eresourceerp quotes 3 months, and Orchestra software estimates 6 weeks.

Full disclosure: I am the CTO of Formever Inc. which has developed such a system. It was done in response to what I saw was a need to bring down the time to develop ERP systems to less than a month and allow it to be done by business people rather than expensive IT professionals.

In contrast to long ERP projects a short project doesn’t have to deal with changes. Your company almost certainly won’t undergo any unanticipated
changes in that time, the project team will not change in just a few weeks, and the budget will be far lower simply because there are fewer hours being expended in the implementation.

Even if such a project goes 100% over budget, it’s still only a few weeks.

If the time is short enough, by the time the consultants present an
invoice you will have the system or enough of a look to do a good
evaluation. If it doesn’t fit your needs, you have the money and they
don’t. That’s a much better negotiating position, one with the cards in
your hands instead of the consultant’s.

For further information on the problems of enterprise systems read my book: Avoiding IT Disasters: Fallacies About Enterprise Systems and How To Rise Above Them