BEWARE Requirements and Responses

Requirements gathering begins early.  Mostly worked on by the presales and sales team, stakeholder committees, SMEs, and other influencers, it will eventually impact the future state of operations that are naturally going to be impacted by the service or product being adopted.  Thus, it’s essentially important to be careful, especially on the consulting side when considering your answer.  And, on the stakeholder/adoption side, especially careful when accepting an answer.  Let’s look at the most common scenario we all face: does your solution do “XYZ” out of the box?

The temptation exists on both sides on the service provider side and on the customer side.  The pressure is always on consultants to create and on the customer to always prefer a “YES.”  To test this, you could even put an absurd question on the RFP, “Does your software perform acrobatics?”  The most likely answer would be “Yes.”  However, the true-er answer in such cases is more to the tune of, “The software/service handles air-to-air transfers and tight-rope walking.  Additional scenarios can be accommodated for as-needed, however setup and configuration are required.”

As always, many will yield to the temptation to accept the “YES!” as the end-answer.  And beware, because like everything, life is not so simple.  The real work begins when both sides start to actively work to determine exactly how closely the particular customer requirement can be achieved.  In working together to find out the real answers to your requirements questions, here are some basic tips:

• Make sure that “YES” is not an answer in itself. Even truly “out of the box” items are most likely not such.  No solution works in a vacuum. ERPs and CRMs, as advanced as they have become, are plug and play.  The fallacy is that many consider them as such.  Configuration is most likely required, even if it is a simple toggle of a single option. To prevent falling into this trap, don’t allow for simple Y or N answers, but determine what is required in the answer itself.  Make your respondents answer by using responses such as “some configuration required”, “extensive configuration required”, “some development required” or “significant development required” to achieve the desired transparency in your result.
• Embrace and welcome feedback. If the consultancy or vendor competing for your business has follow-up questions about how you will use the application, by all means, provide them with enough information as to be relevant and address your specific use cases.  If you can do this, your proposal will surely have more accurate information for your team to assess later on.
• Embrace and welcome feedback. If the customer has feedback or further questions, consider this a good (no, consider this a GREAT) event, it will be your only way to ensure that your solution is aligned with their needs: remember, all feedback is welcome.
• Be realistic. The core of “why” any company exists does not live inside a solution. Solutions are there to organize and run operations, goals, tasks, and will be nature need to be flexible and ready for updates.  Yes, systems are vital, and so are requirements, but both will rely on all parties having a clear understanding of that distinction.  The best way to be realistic is to consider what your upgrade, update, and maintenance path look like beyond adoption, to the next steady state.

Hopefully, with these guideposts in mind, you can better review responses, or if responding, “YES” to every checkbox requested, hesitate somewhat.  There is never one solution that fits every scenario all the time, and even if it did for a season or two, as business needs change, so will the requirements as well.  Your responses and/or system should respond, accordingly.