Why your ERP implementation is out of time and out of budget – Part 1

This article is part of a broader series on common issues with ERP implementations and how to avoid them. Make sure you check out all other parts by following this link!

Part 1. Unrealistic expectations

Due to the high cost associated with implementing a new ERP, there is often a certain bias in expecting an immediate and visible return on investment. In the most dangerous case, this can generate an unhealthy expectation of quick results, with the unspoken assumption that the new system will replace an often 10+ year-old customised legacy system in a matter of a few months and outperform it throughout every company division from day one. However, this is feasible pretty much the same way nine women can deliver a baby in one month (sorry my project manager friends).

The main reason for this impossibility is that there are technical limitations on how much one can compress or run activities in parallel during the full cycle of an ERP implementation. On top of this, software implementation projects see a negative correlation between development time and quality of the deliverables, which is to say that pressure of time usually causes some activities to be skipped or executed in a sloppy way. Due to the interconnected nature of each component of an application, this lack of care may result in the whole product being critically affected, leading to an overall reduction in quality and eventually delivering a poor performance. (Still, it is worth noting that the opposite is not necessarily true: extra time by itself does not automatically ensure higher quality.)

Another common assumption is that the effort terminates as soon as the ERP goes live, and the system will become sort of self-sustaining after that moment. In reality, a new set of challenges begins once the system responsibility shifts from the implementation team (often external) to the support team (often internal). While both pre- and post go-live stages require at the very least a good knowledge of the system, different abilities are involved for each of them, the same way you need skilled people to build a car and differently-skilled people for its maintenance. Both are required if you expect the car to function well as soon as you start driving it, and to keep functioning for a long time while you keep driving it. In the case of software implementation, the right knowledge has to be shared in the form of training people and documenting procedures.

So how does the above actually manifest itself? Let's have a look at how things could play out.

Worst case example: the interface between our ERP system and the main supplier is expected to be designed, built, and delivered in three weeks. This timeline turns out to be insufficient to implement checks on stock availability and purchase order changes, so they are neglected. The interface goes live late and is unfit for purpose. When the problem is identified and escalated to be addressed, the implementation team has gone and no documentation is available to understand how the interface actually works. End users start to use Excel to track the stock available at the supplier, gathering such info via a series of emails, and they use a colour-coded system to flag any purchase orders to change. Data and logic start to thrive outside of the ERP system, reducing its efficiency and rate of adoption, and in turn skewing a few KPIs in the system dashboards for senior managers.

How to avoid it: do not make assumptions if you have no experience of ERP implementations, and take with a pinch of salt what is said during the pre-sales phase. Take initial estimates for what they are, estimates, and rely on an independent and competent third-party to stress-test the implementation plan and the timeline. Ensure competent resources are allocated at the beginning of the project and their time is safeguarded throughout its duration. If time gets tight, do not force deadlines but rather identify what parts are behind schedule and understand the risk of leaving them out as opposed to proceeding anyway.