As with any project out there, be it building a single- family house, writing a software app, implementing ERP system, or upgrading the state’s electrical power grid, scope management is something that is critical for the overall success of the project. The implications of improper scope management can be far reaching and have a devastating impact on the project’s timeline and budget. It can turn an otherwise successful project into an utter failure in the eyes of the client.
Scope Management is a set of tools used by the project team to ensure that the scope of the project is accurately defined and mapped, that work being performed is only what’s required for the success of the project, and resources used on the project are utilized with utmost efficiency. They are:
- Project Definition
- Change Management
- Creep Review
Properly utilizing these tools will ensure that a client’s expectations are properly managed and met.
Requirements SOW
Within the ERP Implementation project, Project Scope is not defined in a single document, but rather a set of documents that are delivered at different times within the project window. This is because the ERP Implementation project can be thought of as two separate projects – one to deliver project documentation and complete budgetary estimates, and another one to implement the ERP. We begin with the Requirements Statement of Work (SOW) that outlines the first part of the project: what will be done to get the Business Requirements Document (BRD) drafted and agreed upon and to produce the Project Budget Gantt document.
Requirements SOW must outline which organizational units will be approached for the purpose of requirements gathering and possibly becoming a stakeholder of the project. SOW will also contain what will not be included in the project scope – if or when such things become obvious during the pre-sales process. The goal of the SOW is to identify the budget and timeline of getting to the BRD and its approval.
BRD and Implementation SOW
A signature on the BRD also means signature on an Implementation SOW. It is most common in the industry to have the Implementation SOW rolled into the BRD itself as an appendix, but I’ve seen it as a separate document as well. The difference is if you want to be able to collect signatures on two separate documents or one. In either case, to avoid the potential scope creep, BRD must be a complete and definitive list of all of the business processes, assumptions, and constraints. It should also outline key stakeholders of the project, Risk Management and Change Management processes and procedures. BRD must also outline what is clearly not within the scope of the initial implementation. Examples of that could be some third party system that will be integrated later on, or a module that will not be implemented at the initial Go-Live but at some point in the future. If your budgetary figure does not include it, but the client wants to potentially use it in the future, do yourself a solid and outline it as “not within the scope”- you’ll thank yourself later. Possible project constraints should also be outlined in the BRD as a separate appendix or a separate accompanying document. This includes anything that might delay the project, limit final functionality, or negatively affect the timeline of the project, including procurement delays, lack of resources, scheduling conflicts, or possible timing delays. Last but not least, your BRD must include User Acceptance Testing (UAT) procedures and acceptance criteria. It should also contain maximum time that end users can take to get the UAT wrapped up.
Change Management – avoiding scope creep
As you begin delivering your ERP and as User Acceptance Testing begins, there will be many questions from the end user that will sound something like this: “Can we make A show me B” or “Can we change C to perform D” and so on. Some of these questions are a result of trying something new and realizing it works differently than in the old ERP. Sometimes it is the misconception about how something works or should work. Yet sometimes it is a result of the business process not jelling perfectly with the ERP’s default functionality. When that happens, change might be needed. And at that point it is critical to follow your change management and put it through a correct process:
- Gather requirements
- Create Change Order (CO), outlining budget and timeline impact
- Approve CO with the client
- Include CO activities on the project’s schedule
- Implement CO changes.
Please avoid the temptation to “just do it really quickly over here” – doing this can first and foremost lead to unintended consequences. Secondly, and just as important, it tells the client to always try to convince you that this other little change over here “should just be done”. Before you know it – you’re drowning in little changes and the project scope is out of hand.
Conclusion
Managing project scope on the ERP Implementation is all about careful documentation of the business requirements, proper change management, and careful management of client’s expectations. Spending time on the requirements gathering stage and carefully documenting the desired solution in the BRD can save the implementation team a lot of time and effort down the road, ultimately ensuring the success of your project in the eyes of the clients.
Author bio
Greg is a President at FiduciaSoft, the company he founded in 2015. As a provider of custom software development services, FiduciaSoft helps small and medium-sized businesses keep up with the times. Prior to founding his company, Greg has been working in logistics, manufacturing, and retail businesses as an IT consultant for over a decade and a half.
