How do you manage ERP scope creep and change requests?

I would also add some percentage (1-10%) of scope creep to the project. I have not found a single project without scope creep. Depending on the organization and the experience and knowledge of the business process owners. Scope creep should be expected, thus the need to establish the change management processes up front is required.

From my point of view, the lack of requirements understanding and what are problems that need to be addressed are factors of the scope creep. Hence, the project team should share the same understanding the requirements and focus on problem that need be to be addressed.

Oftentimes, what is written in the scope definition is either not what the stakeholders meant or it is ambiguous. Clarifying what is needed and getting a common understanding of the ambiguous statements is key to keeping scope creep at a minimum.

To build on what the author proposes, mitigating scope creep and change requests could be addressed early on in the sales cycle with thorough and meticulous discovery and requirements gathering. Engaging broader teams from both sides to clearly define and agree on mutual expectations for the scope. From the sales side, pre-sales and a senior professional services representative should participate in the conversation. From the customer side, process managers need to be involved as early in the discovery, as possible. Assumptions will also need to be clearly articulated as early as possible and understanding of the scope should continue to be confirmed throughout the sales cycle.

Like any other project, it is beneficial to develop as tight and descriptive a scope as possible, prior to project kickoff. It is also important to understand that ERP projects fulfill the goal of improving the Planning for the Enterprise’s Resources. Ideally each project should be viewed as a continuous improvement effort spanning multiple project phases over time, and not necessarily not as one mega project to solve all challenges. Allowing for scope creep, ignores the continuous improvement view and potentially jeopardizes project schedule, cost and ultimate success. Keeping these simple viewpoints can serve as success drivers for the business’ ERP project, as initially framed and approved.

Mergers, acquisitions and divestitures often leave siloed ERP systems. Added to these systems are SAAS models, data platforms and third party systems. An implementation is the appropriate time to define and execute a data strategy. This north star defines how data will be entered and utilized going forward as well as establishes the policies to which all must adhere, including third parties. This does not eliminate the need for the ETL exercise, but will allow the company to be more agile, resilient and utilize data driven decisions going forward. Data driven decisions can be a key competitive advantage, especially when Intelligent Automation, AI or Cognitive intelligence are layered on. There are even tools now which will do the mapping :)

It depends on whether you are migrating from one ERP system to another or if you migrate from various spreadsheets or such to an ERP system. The former is fairly easy because the data is structured and documented. It can't hurt to review data quality though and take the migration as an opportunity to clean up. The latter is way more complicated as there is usually no documentation and it is very likely everyone maintained the spreadsheets or other tools a little differently. In this case, preparing the data so it can be loaded into an ERP system is a project on its own.

The data migration team can address challenges in ERP project management by conducting a thorough analysis of existing data and systems, creating a comprehensive data migration plan and testing strategy, ensuring data accuracy and completeness, utilizing data mapping and transformation tools, and collaborating closely with all stakeholders involved in the process.

I do not believe this to be a technical challenge. Technically this can be accomplished using the proper tools. The challenge is really understanding and determining how much data the business really wants and needs to transfer. Will they really use this information in the new ERP? If a reporting need for history is identified, then utilize data warehousing and BI reporting to resolve.

"Data migration" makes it feel like the challenge is one of data transfer and data transformation which is completely accurate but not complete. The reality of data migration is when going from a prior system to a new system the new system has a) Capabilities that are significantly different from the old system b) Capabilities that are net-new to the ecosystem c) Capabilities that are no longer in the new system. In each of the above cases determining handling and driving alignment with business stakeholders is critical.

It is important to know if the implementation of the (new) ERP system is user-driven or management-driven. In a user-driven scenario, the acceptance of the new tool is less problematic than in a management-driven scenario.

One ERP implementation project always stands out to me to illustrate the value of change management, training and change culture driven from the top down and bottom up... or, in this case, those elements were missing. At go-live the warehouse fulfillment rate dropped to 50% fulfillment rate pre go-live of the new system. After a few days without moving the needle, it was determined a new shift of temporary workers would need to supplement the day shift to catch up. The first night the second shift/temp team hit 100% of baseline. The next night 120% and the third night 150%. The route cause was the lack of adoption to the new process. Change management is priority when determining time to value on your ERP project.

To ensure the success of ERP projects, corporate leadership must prioritize the corporate change management process, involve key stakeholders in developing a comprehensive user adoption strategy and training plan, provide ongoing support and communication, incorporate change management techniques to address resistance to change, tailor training to users' needs and roles, conduct regular assessments and evaluations, and ensure training covers both technical aspects and business processes and benefits.

ERP implementation is usually starts with a long list of desires from stakeholders. The desire list is scoped abd narrowed further. While implementing the scope, stakeholders creative mind peeps in and changes the scope. This leads to time & cost overruns. Therefore- step one should be to implement the scope that’s agreed at the very beginning. Scope out versions and spread out the desire lists in multiple versions. This will make your version 1 go live much within Schedule and cost. You will start seeing ROI and br able to measure value out if the system. Enhancements in following versions will add to the ROI. The key is to implement a version one without making alterations while implementing version one,