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

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 5. Unchecked scope

A project is defined as a temporary and carefully planned endeavour aimed to deliver a specific outcome, subject to given constraints such as time or cost. An ERP implementation fills this definition perfectly and is effectively considered a project. However, one of its peculiarities is that customers are often heavily involved in the effort, collaborating closely with the specialists who are actually expected to deliver the results. This sometimes causes a problem around the outcome: the issue is not so much defining it, rather keeping it constant throughout the whole duration of the project. Since an implementation does not follow a ready-made path, and considering that stakeholders might have different or even conflicting interests, the outcome could be modified by the authority of stakeholders and their ability to influence decisions.

The most common way this occurs is through requests to include specific functionalities in the system at the time of go-live. Choosing to adopt an ERP might be the result of a decision of the upper management and fit a broader strategy for the company, but middle management and end users often see the introduction of the new system from a different point of view. Their perception might include concerns of losing control over their work, lacking functionalities available in the previous software, or seeing increased labour to carry out frequent tasks. The situation can be worsened by lack of involvement or training and, when this happens, stakeholders will demand changes to adapt the new system to their current needs, rather than taking the time to understand and learn the new software and how it can benefit them. If no filter is in place and all requests are granted without any form of control, the project scope will inflate considerably, paired with complexity and workload. Trying to do too much and not accepting anything less than a perfect system may eventually put at risk the whole go-live.

So what causes this situation in the first place? The fact is that companies expect to rely on an ERP software for years (sometimes even decades), so it is obvious that all benefits will not be realised immediately, instead the system capabilities will be utilised more and more as time passes. This implies drawing a line to understand what is to be delivered at the time of go-live, hence in scope during the initial implementation, and what is left out and postponed to a future phase. It is very, very unlikely that this decision will make all parties equally satisfied, plus further tension could emerge as the implementation progresses and various use cases are discussed and excluded if needed. Aside from the tools of company politics or exercise of authority (not in scope of this article anyway), some formal change request process should be in place to handle any modifications to the original project scope. These modifications tend to be more disruptive when no effort is put in creating precise documentation to outline the nature and extent of the work, fostering alignment between stakeholders, and ensuring sufficient involvement of all parties in defining the solution. Consequences include repeated meetings to discuss the same topics, frequent rework and inability to track progress, and an increased difficulty in defining and reaching milestones.

Once more, let's now consider a realistic scenario to understand what could happen if the scope is not kept under control.

Worst case example: a company makes the decision to keep running the legacy manufacturing software, to be used in parallel with the accounting functionalities of the new ERP. During the analysis phase, all use cases of the production stream are taken into account, but an arbitrary decision is made to interface only the most common one and leave the rest manual, to ensure a timely implementation. When the interface is ready to be tested, the production manager realises the additional labour required and demands for other production cases to be handled by the system. He manages to leverage on the fact that the scope of the interface was not outlined in any formal document, so the amendments are approved and the interface redeveloped. Following this example, other stakeholders demand additional functionalities. Under the insistence that these are essential for go-live, they encounter no opposition and their change requests are included in scope. This happens multiple times, to a point where the extent of the changes spirals out of control and renders the initial system design unusable. The user acceptance testing is failed on multiple fronts, and the upper management is forced to postpone the go-live.

How to avoid it: ensure the boundaries of the project are well-defined and it is clear to stakeholders what is in scope and what is not. Promote involvement of all parties and make sure they are comfortable with the solution to be adopted, to avoid any future change of mind. Put in place a formal process to submit, consider, and approve or reject any change request presented by stakeholders. Rather than immediately assume a change to the system is the only acceptable solution, consider relying on workarounds to ensure the implementation stays on track, even at the cost of causing some slight dissatisfaction to end users.