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

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 4. Unsound sequence of activities

Implementing an ERP system is a complex project, and as such it is often broken down into different phases. In all but the simplest of scenarios, it is likely that the whole company will not go-live at once, rather some functional areas or national divisions will start using the system first, which will then be rolled out to more countries and gradually replace other systems used by employees. The decision about the implementation sequence is usually made in order to reduce complexity or disruption to business operations during the project, but this approach sometimes neglects the IT principles and technical requirements needed to build an ERP system correctly and ensure it functions properly.

The key concept to grasp here is that an ERP system is a collection of data and functionalities that are built on top of each other and therefore must respect a set of dependencies to work without issues. Likewise, it is important to understand that ERPs were born out of the need of combining back-office functionalities (accounting and financials) with the operational capabilities (manufacturing) provided by MRP software. One cannot expect a self-sufficient implementation only within a particular functional area of the company - maybe because the management is struggling with it and wants a new software in place - without assessing first and foremost the financial model followed by the business, which must then be replicated in the ERP as a starting point for all other functionalities. Focusing on advanced functionalities without having covered the basics first will inevitably lead to discovering key parts missing at a later stage or experiencing instability due to weak foundations, with a skyrocketing cost to fix the situation.

Another common issue is failing to adhere to a clear methodology throughout the implementation. This can happen due to a poorly drafted project plan, which ignores the correct steps to follow for a good ERP implementation, or due to external events applying pressure on the project, causing deadlines to shifts and priorities to change. External events may include a substitution of the project sponsors or decision makers, a reallocation of the budget within the company, or a shift of strategy decided by the board. While these events could be unavoidable or unforeseeable, what is too often neglected is the mitigation of their impact on the project, sometimes coupled with the assumption that changes to the original goal and scope can take place immediately and without any pain. This actually causes a lack of consistency in carrying out the implementation, which appears as tasks undertaken too early or too late during the project, a repeated focus on low value added activities, possible rework and repetition of the same tasks over time, and a general lack of cohesion and coordination in the work carried out by the team. These occurrences are so dangerous that they can prevent the delivery of a robust system, and even jeopardise the whole go-live.

Let's now see how this could actually happen in practice.

Worst case example: a sales-focused company decides to implement an ERP system starting from the integration with their CRM system, in which the master data are kept. The project progresses with a strong focus on the sales stream and interfaces, and eventually reaches a point in which the lack of basic data and configuration in the system prevents meeting the next milestone, forcing a meeting with the upper management. The project sponsor is replaced, and the new one adamantly asks for a prototype of the system to understand the status of the implementation. Since no data migration was carried out, the implementation team is forced to use sample data. By the time the prototype is ready, the project is severely behind schedule and only a small part of the prototype fits the criteria of the deliverable. Given the repeated lack of progress, the upper management eventually decides to cut the budget, so the project is put on hold.

How to avoid it: ensure a robust project plan is in place at the beginning of the project and is reviewed regularly, together with the actual progress. Stick to a tested methodology for the implementation and double check the dependency between tasks before allocating resources to them. Avoid any change of direction in the middle of the project, keep all stakeholders informed about the need of following the implementation plan, and carry out mitigation in case of unforeseen events to avoid a debilitating impact on the project.