Managing Requirements Changes on Enterprise Projects
Based on the methodology of your choice, the requirement sign-off process may occur at different phases or frequencies. Independent of the way you run your projects, the sign-off on requirements is an important step in any and should not be undervalued. In an ideal waterfall world (which I believe to be least optimal model for complex projects) once requirements are completed, reviewed and signed off, the project scope is set in stone. Unfortunately, this is a rare phenomenon.
In this section of the “Keys to Success for Complex NetSuite Implementations” blog series I’ll discuss some of the reasons why changes to requirements occur, best practices for change management and some tools that can help.
In the previous segment of this blog series I highlighted some best practices for requirements gathering such as ensuring to include all impacted stakeholders and using highly experienced functional consultants. Following these best practices will help to limit the volume of late breaking changes but, some change requests are usually unavoidable.
There are several common causes of requirements change requests:
1. Failure by the client team to communicate a requirement. This can occur if some functionality is assumed as a default or the underlying process changes or downstream impacts are underestimated.
2. Failure by the client to fully understand the business specifics.
3. Failure on the consulting side, to correctly translate a client need to the future state.
4. Client and Consultant having a different understanding of a given process or requirement. This often occurs when there are differences in understanding of “common” terminology.
5. As Business Process Leads begin UAT they may notice the system behavior is not what they originally envisioned.
6. End users may point out process inefficiencies caused by the implemented solutions.
7. Requirements are written with a lot of detail assuming a specific design solution which is later deemed to not be the ideal solution.
a. A best practice for avoiding this risk is to perform a Proof of Concept (POC) during Requirements Gathering for more complex/unique solutions and customizations.
Change management is a process that enterprise clients tend to have more rigor around than smaller clients due to more sophisticated budgeting and audit requirements. I make a point to learn each client’s process for reviewing and approving changes to requirements at the beginning of the project. Ideally, the change management process and expectations are set and enforced from the top down. Any time that is not the case, set these expectations during the Requirements phase with full support from the project sponsor(s).
Any changes to the signed-off requirements need to be careful considered and agreed upon. Readily agreeing to seemingly small requests for changes, can inadvertently open the flood gates to scope creep and have undesired side effects with respect to cost, quality and/or schedule. Additionally, accommodating changes from stakeholders outside of the defined process can back-fire. For example, if the process is not followed and QA is not aware of a change, their test-cases will not be updated for it and this will result in unwarranted defects during testing. Likewise, if operational readiness SMEs aren’t expecting a change it won’t be reflected in procedures and training documentation delivered to the users.
One practice I have found to be extremely useful on large implementations is capturing requirements in a design document. This is a great aid for all phases of the project, reducing the number of change orders as the requirements and solutions are clearly documented, understood by the client and available for future reference. It also helps when working on cross-functional solutions which may impact multiple consultants that are responsible for different work streams. The document template captures all business requirements related to a given process with a reference to the solution design, solution assumptions, use cases and all required configurations. For companies that prefer working in a more agile mode, obtaining sign-off at this phase can be beneficial as it allows the implementation team to have multiple process iterations, optimize the solution, demonstrate some aspects of the solution with the client and if required adjusting the requirements.
For significant change requests that impact cost or timelines, it is imperative to obtain approval from the project sponsor and key stakeholders and communicate them to the entire project team. Finally, approved changes should be documented with updates to the requirements and existing designs.
The key tracking aspects for change management include:
1. Comprehensive log of all changes along with associated cost or schedule impacts (where applicable)
2. Approvals from project sponsor and key stakeholders
3. Communications of change notification being sent to all team members
4. Updates to impacted artifacts such as requirements, solution designs, test cases, training materials, change order/SOWs (where applicable)
5. Analysis and resolution of cross-impacts to other processes/systems etc.
6. Plan for migrating the code or configuration changes through various environments (sandboxes)
Finally, for small implementations, tracking requirements changes can usually be managed easily via verbal discussions in meeting, emails or a simple change log in a spreadsheet. However, these rudimentary tools can quickly prove inept on large projects for enterprise clients. I recommend the following blog post recently published by Strongpoint.io (formally called FLODocs) highlighting key aspects and advanced tools for managing this process: https://www.strongpoint.io/en/resources/blog/scale-netsuite-change-management-organizations-size .
Continue to part 4 of this series.
(877) 563-1405
