Is Your ERP Transformation Project Not Living Up To Expectations?

It all started off well enough; you organized a project team, documented your needs, evaluated vendors, and negotiated an agreement. Now the excitement and momentum generated by all that activity has bogged down into a series of pointless meetings, disenchanted users, and mounting costs.

Where did it all go wrong?

You can’t point to one piece that went awry in projects that have the sensation of quicksand sucking in productivity. More often, it comes from a multi-pronged monster taking over the situation. Let’s break it down:

Project alignment – While management had a vision of the current state of systems, the user vision of how they operated was quite different. Comments of “that won’t work for me” usually are an indicator that the requirements documentation did not go quite deep enough and more needs to be done to overcome this challenge. 

Vendor selection – This is prevalent in quite a few vertical market offerings. Vendor A says they support your technical and business requirements. Let’s say it’s for food and beverage. They have slick marketing literature stressing their ability to support the vertical, and the demonstration looks great. Then the implementation team arrives and begins learning the actual business process and suddenly that great functionality starts looking a little thin. 

User training – A popular option for today is the ‘train the trainer’ approach. However, most companies don’t have an available resource who can actually perform this task. This leaves the workforce depending on the initial trainer who is stretched too thin and not sufficiently trained. 

Infrastructure incapable of supporting the chosen software – Companies using older legacy products typically have not kept up with the state of current technology. Networks and PCs that supported those products may be woefully inefficient at operating the new software properly. The result is a slow screen process and record updates. To the user, it seems the new screens are slower that the old product they used for the last 20 years. This can quickly impact user adoption in the wrong direction. 

So, where do we go from here? Not all is lost. While in some cases companies have simply bought the wrong software, more often than not, it is still salvageable, if not ideal. The goal from here must be realignment and then a detailed plan forward to accommodate the pieces that have been sucked down into nonproduction. 

Today’s packages are very flexible so there may be the opportunity to tailor your chosen package to build a workable system. If this is the option you must take, then be warned: customizing a system without a detailed objective and plan can be costly and ineffective very quickly. Your best option at this point is to go back to the beginning, or what will certainly feel like the beginning, and conduct a thorough gap analysis of best practices versus the real capabilities of your chosen software. This analysis will be your best option to turn the project around properly and effectively. The plan going forward may use both modification and point solutions to achieve a successful implementation.


If you take something away from this article, let it be these points:

  • Analyze why the project got bogged down

  • Acknowledge and plan for the steps needed to turn it around

  • Know that with any modification strategy, you must pay careful attention to both scope creep and actual functionality in order to assure staying within a workable budget

Finally, it is difficult to accomplish this challenge on your own. If you can relate to the situation I described, give Knowledge Path a call.