The vendor selection process, whether it be for a new association management system (AMS), certification management system (CMS) or other system to support your business needs is a time-consuming, costly and often difficult process to navigate. Which solution actually fits all of our requirements? Which company can be trusted to resolve an issue in a timely manner? Are the costs prohibitive or within our budget?

As a long-standing vendor in the credentialing space, Prolydian has participated in hundreds (if not thousands) of demonstrations, responded to countless RFPs and supported organizations at every stage of system evaluation and implementation. Consistently, we’ve found that there’s a question that sometimes is not asked or contemplated fully by organizations prior to and during the procurement process: Have we correctly and fully defined our requirements?

What is a requirement?

A business requirement defines the criteria needed to fulfill the business process, rule, etc. An effective business requirement defines the high-level objective — for example, a certification program may have a requirement that all initial eligibility applications must be reviewed before the person can take the exam. That requirement, while certainly describing what has to occur, does not provide enough detail regarding how it happens. Providing such a requirement without any supplemental information may not result in a system that’s truly capable of supporting the how.

Functional requirements further expand on the business requirements to define the how behind what must occur. Building off the initial application review example, a functional requirement should further explain the exact method and process by which the review must occur — this includes how reviewers are assigned (randomly, round robin, always the same person), how many review stages there are and when each stage applies. For example (some detail omitted for brevity):

• Candidate submits an initial exam application.
  • System assigns a reviewer from the available pool (round-robin to maintain an equal distribution of workload).
• First reviewer decision:
  • If approved → Candidate receives approval email and may register for the exam.
  • If rejected → A second reviewer is automatically assigned.
• Second reviewer decision:
  • If approved → Candidate receives approval email and may register for the exam.
  • If rejected → Candidate receives rejection email.

In the illustration above, we can see that the combined business and functional requirements have provided us and the vendor with enough detail to determine whether the system of interest is capable of handling such a review workflow.

Another important aspect of a requirement is its priority — is this requirement an absolute must-have to maintain business continuity or is it a nice-to-have requirement to simplify, automate, or otherwise improve upon the existing process. Prioritization is especially important to ensure critical business functions are accommodated by your selected vendor. Following vendor selection, proper prioritization ensures vendors understand the order in which to focus on various requirements — less weight is placed on “nice-to-have” requirements, as they’re typically addressed at project conclusion if time (and money) allows.

Why does this matter?

Defining your requirements may seem like a technical step, but it’s one of the most critical parts of the process. It sets the stage for everything that follows from the vendor you choose to how smoothly implementation goes, to how well your system actually supports your team. When requirements are vague or incomplete, that’s when the real problems begin:

• Misunderstandings
• Inadequate functionality to support business needs
• Unexpected work and cost
• Procedural workarounds that reduce efficiency
• Timeline delays
• Incorrect prioritization

Beyond the obvious impacts of the above, such incidents run the risk of impacting the crucial relationship established between you and your vendor. The vendor-client relationship is crucial to ensuring a long-lasting partnership between the organizations. First impressions matter quite a bit — issues during implementation often lead to a strained relationship that can, at times, be difficult to repair.

Taking the time to fully define your requirements, both business and functional, prior to beginning the vendor selection process serves to narrow your vendor search by confirming functionality upfront and, ultimately, reduces the required implementation time as such requirements help serve as an implementation roadmap.

Beyond the benefits to the vendor procurement and implementation process, these requirements can help you document core work processes as well as identify any procedural inefficiencies. Are you having to manually create, edit or otherwise manage aspects of your certification program that could potentially be automated? Requirements help you answer that question and allow you to consider automated alternatives to improve operational efficiency and reduce costs.

Who’s responsible for defining requirements?

Well, that depends! Typically, defining requirements is a team effort — those responsible for managing the day-to-day operations of the program should define their own business and functional requirements, the finance/accounting teams should define their business and functional requirements, and any sort of requirements related to integrations or technical work should be the primary responsibility of a development or other technical team. It’s important, however, to ensure requirements are reviewed across teams as they’ll often affect one another. These requirements shouldn’t be created in a vacuum — they should be created through a collaborative effort, reviewed internally and refined to ensure they capture all necessary details. This should be an iterative process whereby additional detail is added within each iteration.

Key Takeaways

The vendor selection process is already a stressful and time-consuming endeavor with far-reaching impacts. Defining requirements upfront can reduce the likelihood of making the “wrong” selection decision. You should also work collaboratively within and across teams to fully scope out and define your requirements. Work iteratively to further refine and define. Use these fully defined requirements to identify any operational inefficiencies and note the potential for automation.

When the time comes to add a new system or switch an existing one, take the time to document both your business and functional requirements in advance. Though this effort is time-consuming, it ultimately saves time by preventing misunderstandings, timeline impacts, cost overruns, impacts to the vendor-client relationship and more serious effects such as inadequate functionality requiring manual workarounds — your system should work for you, not the other way around.