180 Systems _ Requirements Overload

Requirements Overload

| 1032 Comments | Michael Burns

There are times when defining requirements for an ERP selection process that our client would question the effort and think that we are too much in the weeds and should save this detail when evaluating the systems and implementing the system. A leaner approach does make sense for standard requirements, but if the client has complexity and unique processes, then detailed requirements are worth the effort to:

180 Systems erp Requirements Overload

  1. Avoid costly change orders when vendors discover what is needed during the implementation – It’s sometime called scope creep and you’re damned if you make the change as it will likely delay the project and be costly and damned if you don’t as your employees or customers will not be happy. Hopefully these changes can wait for phase 2.
  2. Support objective comparison of systems with vendors demonstrating your critical requirements rather than what they do best – It’s critical to give the vendors a script for the demonstrations. We typically have 2 demonstrations – the 1st based on some of the critical requirements and the 2nd based on some of the business processes.
  3. Ensures stakeholder buy-in by reviewing and approving the requirements – ERP projects are strategic, costly and require stakeholder buy-in. Stakeholders can see the forest for the trees and help with prioritization – they know what’s critical. As well, these projects can have a big impact on the future of their company. You want to give them every opportunity to bless and support the project, or if not satisfied, make changes or cancel it.
  4. Improves contract negotiation by defining scope in detail rather than in a high-level way, which is the preference of the vendors. Our recommendation is that the implementer defines scope based on their response to the requirements in the RFP.

However, not all requirements are critical and there’s no point in wasting a lot of time on non-critical requirements. Our approach is only to ask the vendors to respond to the critical requirements (20% on average). This will improve engagement by the vendors and save time for the vendor and the client, who don’t need to answer questions about non-critical requirements. Later, in the selection process, the vendor will readily respond to all the requirements when there are only 2 vendors still under consideration.

Although it’s tempting to simplify the ERP requirements process, do so at your peril.

1,032 thoughts on “Requirements Overload”

Leave a Reply

Your email address will not be published. Required fields are marked *

Name