Every ERP implementation eventually reaches the same point. Training and testing begins using real scenarios and someone says: “The new system doesn’t do what our current system does.”
No matter how thorough the requirements gathering process was, new requirements will emerge during implementation. Some are legitimate gaps. Some are misunderstood requirements. Others are simply users discovering a different way of working. This is where a strong change control process and a strong project manager become critical.
One of the project manager’s most important responsibilities is preventing emotional decisions. Users will naturally want immediate answers and, in many cases, every requested change will suddenly become “critical for Go-Live.” A good project manager slows the conversation down and ensures the request is properly evaluated before commitments are made.
Start by documenting the requirement, business impact, urgency, and any available workarounds. Then have the implementation partner assess whether the need can be addressed through standard functionality, configuration, process changes, or if a customization is required, along with the estimated effort, cost, and timeline impact. The implementer should not charge you for preparing a level of effort!
With this information in hand, the project manager can assess the broader impact. A seemingly small request can affect budget, timeline, testing, training, support, and future upgrades. This is why change requests should not be approved by individual users or project team members. Instead, they should be presented to the Project Sponsor, Project Leadership Team, or Steering Committee for review and decision once all information has been compiled and can be presented concisely.
The leadership’s goal is to determine whether the business value justifies the cost, risk, and impact to the project. In general, we encourage organizations to stay as close to standard functionality as possible and every customization creates something that must be maintained, tested, supported, and potentially reworked during future upgrades.
That said, customizations are not always bad. If you’re using the same system as your competitors you gain no technical advantage! If your requirement represents a true competitive advantage or supports the organization’s “secret sauce,” a customization may be justified. The key is making that decision strategically rather than reactively. The reality is that most of our ERP implementations include some level of customization. The successful projects are not the ones that avoid every change request. They are the ones with strong project management, disciplined governance, and a structured change control process that evaluates each request consistently and objectively. When change orders inevitably arrive ensure you have a strong PM and a stronger change control process.
