Selecting an AMS part II by Julie King
Selecting an AMS Part II: Understanding the Importance of Clearly Identifying Your Business Rules
Example RFP Specification: “Certification module that will allow us to assign and track certification points.”
On the surface of things, this looks like a completely reasonable request to include in an RFP for the selection of an AMS. It is the kind of feature request we see all the time.
The problem lies in what is missing. If the association needs any additional business rules or requirements to be met, such as the person needing to be an active member or to pass an exam to be certified, it is likely that the association may get exactly what it described in its RFP, but this will not be what it needs.
This can lead to huge misunderstandings, frustration, cost overruns and possibly even lead to a project failure. So while mapping out business rules and requirements is something most people do not do often in the normal course of their jobs, when selecting an AMS it is important to tackle this task.
Here are some tips that will help you successfully suss out your business rules and requirements.
Focus on what not how: I am a big believer in “outcome-driven design” that focuses on the tasks someone needs to accomplish when using software. Outcome-driven design takes the perspective of what the software needs to do, rather than how it needs to do it. Quite often staff will want to focus on the hows, which can drive up costs and result in unnecessary customizations being added to the software. The key is to guide your staff to outline what outcomes they need to achieve in quite detailed terms, without having them dictate exactly how the software needs to behave or flow.
Identify your “corner cases”: Corner cases are the outliers, the scenarios that break the rules. Computer software programs are inherently sequential and as such inherently bad at handling corner cases, yet there will be situations where the system will not be viable unless it is designed to handle a corner case. For example, membership dues. Many associations have some pretty complex rules for pro-rating dues that the AMS must be able to handle for it to help rather than hinder the work the association does. You need to first understand your corner cases and then determine if they need to be handled by the software or can be handled manually on a case-by-case basis.
Break down the demos: The most important thing I can tell anyone who is in the process of selecting an AMS is to use the standard system whenever possible. Book system demos and see how much of your daily requirements can be met with standard systems already on the market. You will then need to probe to see how each vendor handles customizations, to ensure that the system you are considering can be adapted to meet your custom rules and requirements as well. Then concentrate your time and energy when working with vendors on how your customizations will be handled.
Slow down: Identifying and mapping out business requirements uses what Nobel laureate Danielle Kahneman describes as “slow thinking”. Most people prefer to use fast thinking and our hectic lifestyle adds to this tendency. Yet when it comes to mapping out business requirements and rules, slow thinking is a must. Book the time and make it so.
Seek input from and harmonize your team: In a perfect world all relevant stakeholders would be engaged and the AMS selection process would ensure that the needs of each system user was met. Yet this rarely happens. In the most extreme case I have seen, three separate teams in an association had three completely different understandings of something critical to membership. As a result the RFP identified a feature that met the needs of one team perfectly, yet paralyzed the ability of the other two teams to do their work effectively. As it happened the teams had been working at cross-purposes for years, but didn’t realize this because they were all using ad hoc, off-line processes. There were some bumps in first getting this recognized by everyone and then creating a unified design that everyone agreed to, but eventually this was worked out. It would have been a lot less painful and more cost effective had this happened during the proposal process, rather than after the initial system had been built. It takes time, but it is important to build out an overview of your internal processes and rules to ensure that everyone is working from the same playbook.
Map out workflows: Workflows are the sequence of steps your staff will follow to perform their job. For example, a membership coordinator might have a process for checking to see if there are new membership applications and then validating and approving new memberships. The steps the person takes to monitor and approve new memberships are a workflow. When selecting an AMS, if you have mapped out the workflows for key staff members it will be much easier for you to validate whether the system you are selecting will be able to help people do their jobs in a streamlined manner. This dovetails nicely with the process of harmonizing your team and is an ideal time to look for opportunities to become more efficient.
Understand the customization “ripple effect”: When deciding what customizations you need in the AMS you select, there can be a time-consuming, and costly, ripple effect. For example, let’s say you request to create two unique user types for logging on to the website. This exact task is done for you, but what is next? You realize that you wanted different user types so you could show different content on the dashboard of the member section, but you never asked for that. Suddenly what was scoped – adding different user types – expands into adding user types and being able to customize the information on the member dashboard based on the user type. This ballooning of scope often comes as a surprise and while the vendor may ask about additional features, in most cases what is requested is exactly what is scoped. To avoid this, you need to think about all the aspects of the feature you would like to have added, not just the initial problem you want to solve.
In conclusion…
It takes effort to identify business rules and requirements, but this will be time well spent when it leads your team to the product best suited to your association.
This process will also help you ensure that the system you select will have the flexibility you need. The last thing you want is to find yourself invested in a system that cannot be adapted to meet your needs. This is most likely to be a concern with pure software-as-a-service (SaaS) systems, as individual clients have very little control over feature changes and additions. While configurations may be available, these rarely are robust enough to handle non-standard business rules.
Which is the perfect segue to the next major point to address when selecting an AMS, which is that when you make a purchase, you need to not just consider what is needed today, but also how future-proofed the solution will be both in terms of its ability to scale as a product and its likely longevity in the software world. This will be the focus of the third and final installment of this series.
