[sch_related_resource]In part 1 of our series, The Path to a Successful Cloud ERP Implementation, we covered addressing personnel bandwidth restrictions. Next up, we are focusing on the dangers of Scope Creep.[/sch_related_resource]
At the beginning of an ERP implementation, a number of decisions are critical to define the scope of the project:
- What parts of the ERP system will be set up?
- Who is responsible for building and testing each component?
- How long will the project take?
Modern day ERP systems are robust with lots of features, some more suitable for a particular organization than others. The availability of so many features within an ERP system can lead to a gradual expansion of the scope, which is known as “scope creep”. Scope creep is when additional functionality requests are made after the project scope is defined. Even though more functionality is an exciting prospect, additional requests outside of the original project scope have the ability to negatively influence the project timeline and budget.
Scope creep can happen at any stage of the project and can have significant effects on the phases that succeed it. A request for new functionality will require new design, additional configuration, extra training, and more testing. A new request later in the project can result in the implementation team delaying various phases of the project in order to re-do work that was already completed. This can result in unnecessary strain on the project budget and hours.
The solution to containing the scope of a project requires having a deep understanding of the agreed-upon project parameters (scope) before the implementation starts. It means that project management will have to identify requests that are out of scope and communicate how those requests will be handled. It is important to review the project scope with all stakeholders during the project kickoff or in a separate meeting at the START of the project.
Every project member should be aware of what requests fall out of scope and which ones are in scope, but this responsibility ultimately falls on the project manager of the implementation team.
Out of scope requests can be handled in two ways:
- New requests might be more suitable for a future phase of the project. This will allow for the entire project team to focus on the more immediate tasks: designing, building, and testing the elements of the system that are most important to the business, with the knowledge that these are not the only changes, but just the ones that need to be put into place first. By doing so, a more holistic view of the project can emerge.
- Sometimes the new request cannot wait and needs to be part of the current phase of the implementation. If this is the case, a change order should be written and signed by both the client management and the implementation team. A change order is an addendum to the original scope of the project that details the additional hours and budget needed to complete the additional tasks. This ensures everyone is on the same page.
Sometimes expansion of scope is necessary to put together the proper solution. Other times it is not needed for the current phase of the project and may put unnecessary risk on the project timeline. The key is to have a full grasp of the project scope and the business needs as well as consistent and clear communication. This will allow the project to stay on-track and help craft the ideal ERP system.
