Home > Blog: Diary of a Cloud Expert > Keys to Success for Complex NetSuite Implementations - Part 2

Keys to Success for Complex NetSuite Implementations - Part 2

Requirements Gathering on Enterprise Projects

In part two of the Keys to Success for Complex NetSuite Implementations blog series I will focus on requirements gathering best practices on “enterprise” level implementation projects.

You can read part one here.

As projects get larger, so does the project team on the business side as well as the implementation side. There are generally more business requirements that need to be collected, more complex solutions to be designed, more configuration and more custom development. Getting the requirements “right” becomes a critical part of completing the project to the client’s satisfaction on time and on budget.

On small implementations, requirements gathering is usually straight-forward. The implementation consultants meet with one or two stakeholders who are intimately familiar with the processes being implemented. They review functionality and present configuration options. The client team can typically provide the necessary answers and guidance needed for initial configuration which is then refined as they walk through the set up and testing.

On large implementations for enterprise clients however, requirements gathering is exponentially more complex!

First, comes the task of identifying the right people for each process or module being implemented. Whereas in a small company this type of expertise and decision making authority may lie with one or two people, at the enterprise level this is usually not the case.

We typically need to involve a group of people comprising some or all the following roles from the client team for each process or department involved:

  • Manager or Director-level Process Owner / Department Head
    • Provides strategic guidance
    • Has decision making/sign-off authority
    • May not know the minute details or pain points
  • Subject Matter Expert(s) or Business Process Expert(s)
    • Often power-users or team leads
    • Know the ins and outs of the process, pain points, limitations, workarounds
    • May not be familiar with cross-functional impact to other areas/processes
  • Client IT team member(s)
    • Could include App Dev managers, Architects, Database SMEs, Developers, Production Support/Help Desk, etc.
    • May be needed to answer questions about current state system architecture (integrations, data bases, data sources, batch cycles)
    • May need to consider impacts/integrations to their other systems resulting from requirements
  • QA
    • Test lead or QA resources
    • May be assigned to participate in requirements for background to develop test strategy / test cases
  • (Client) Project Manager(s)
    • Facilitation / Minutes
    • Tracking Action Items and Follow-Ups
  • Others (not as common)
    • Customer experience advocate
      • Act as the voice of the customer
    • Operational readiness SME
      • Responsible for planning training and transition for users
    • Business Analysts
      • Some clients use their own BAs to write requirements

It is important to ensure appropriate participation up front to have productive requirements sessions. Including too many people often leads to scheduling difficulties, sidebar conversations and distractions. On the other hand, missing a key stakeholder at this stage can spell disaster down the road if an important requirement is missed. As a best practice, I collaborate on the list of participants with key constituents on the client side, such as the project sponsor or a project manager.

When stakes are high, as is usually the case for these large projects, having strong, experienced functional consultant(s) involved in requirements gathering is paramount. Experienced functional consultants possess deep knowledge of system capabilities under a variety of use cases.

They can present a variety of options to clients and drive smart configuration decisions. Their experience should also be leveraged to ensure that requirements capture sufficient details for the implementation team to move forward. Insufficient level of detail in requirements leads to poor design decisions, additional sessions prolonging the requirements phase and/or issues uncovered in UAT. Good requirements on the other hand mitigate risks of extended timelines, cost over-runs and poor client satisfaction.

It should be noted that stretching one functional consultant beyond covering more than one or two process areas can become a bottleneck preventing requirements sessions from being able to run in parallel. Consequently, these large projects greatly benefit from having enough functional consultants to cover the needed process areas as well as a Solution Architect to ensure a sound overall solution encompassing all cross-functional tasks.

To make requirements gathering sessions as painless and productive as possible, I recommend preparing and sending detailed agendas at least a day in advance. Set the expectation that participants should review the agenda and come prepared to speak to the topics. This allows the participants to verify necessary details in advance of the sessions and helps to reduce the volume of take-aways and follow-ups.

I also recommend reviewing standard process flows and high level system integration diagrams with the client team to avoid missed requirements or misunderstandings about how the new system will work. This is a great “starting point” for facilitating conversations with team members who are more visual and helping the team to see the big picture. It is also important to explain that adapting to the standard process flows where possible should be everyone's objective, as it prevents added development costs and increased chance of performance degradation in the future.

Naturally, when working with a team of this size, getting consensus can become a challenge when everyone is not in agreement about either the current state or the desired future state. At times, one stakeholder’s requirements have unfavorable impacts to other stakeholders. In those cases it is not uncommon for the stakeholders to decide they need offline meetings or management escalations to come to agreement.

The final step, is to ensure the requirements are appropriately documented and signed-off on. Check with the project sponsor or the client team’s project manager whether the client has a standard requirements template and sign-off process. Many large mature companies have their own way of doing this that needs to be considered.

For all these reasons, it is important to plan significantly more time for requirements gathering for enterprise clients than small and mid-market clients!

Continue to Part 3

Additional Articles for Consideration:

1 Comment

Leave a Reply

Recent Posts