When discussing technology in the Association industry, it is not unusual to hear association professionals say, “We are different” or “Our dues are too complicated for standard software”. The reality is that while associations have unique missions and visions, many of the core operating procedures are actually the same. Those operations include billing and dues collection, event management, education and training requirements, and many others. These same association professionals believe their uniqueness requires custom solutions, or at a minimum, customizations to their association management software (AMS) as opposed to embracing their similarities to others in the industry. So, they start to layer customization after customization onto their AMS and over time the association is left with a system that is difficult to manage and even harder to upgrade.
Today, many of these association professionals have a new desire to add another layer, they desire to embrace “digital transformation”, the act of integrating digital technology into all aspects of their association. So, they start layering even more technology on top of layers and layers of customizations already on their AMS. By applying newer technology to a flawed or broken process, they fail to transform their association, they actually hinder its ability to move forward…because no real transformation can occur.
The Lure of Faster Horses
I’m reminded of a quote that is often attributed to Henry Ford, founder of the Ford Motor Company, “If I would have asked people what they wanted, they would have said faster horses.” Many association professionals can easily describe the issue, lack of digital transformation, but not the way to get there. They say, “I want to do what I do today but faster and more efficiently”. The reality is that true change, like digital transformation, can only be achieved when you evaluate the total solution as opposed to layering additional technology onto existing processes and procedures.
Let’s talk layers. Small customizations add up over time, and many associations blur the line between “must have” and “nice to have” requirements. When looking at the core functionality of your AMS, it is important to consider if your requirement is a “must have” or “nice to have”…is what you want to change really a showstopper? I’ve heard clients say things like, “We must change the text on the login button from Sign In to Log In”. And, while that change may be in line with an internal style guide, I often ask “Is this change a showstopper? Will current members drop their membership if the button says, Sign In instead of Log In?” The reply is usually, no. This is a simple example of a customization that can be made, but should it? Associations that start making these types of customizations end up with dozens of such alterations. And after a few years, no one will even remember why that decision was made, yet the customization continues to be maintained, year after year.
Configurations > Customizations
Most modern association software is highly configurable, meaning the software natively provides tools from the vendor to change the look, feel, and operations of the software.
Let’s take, for example, setting up custom pricing for an educational webinar. Most association software platforms will allow you to use a formula to determine differential pricing for members and non-members or based on different scenarios: student pricing or a discount annual conference attendees. However, not all software will allow a configuration that says: members who renew at least 2 months in advance of their renewal date, will get 2 webinars for the price of 1, if they buy them in the 2 month window prior to renewal. Let that scenario sink in.
While there may be a technology solution for this, the key question to ask is, “Will this increase the retention rate for members?” The answer may be yes…and it may be no. One must consider the cost to not only customize the solution but also to the association by maintaining the customization through future upgrades. This cost may quickly eliminate any possible gain in retention.
There are good customizations. However, those customizations need to have some guardrails to ensure upgradability and compatibility. Many years ago, I worked for an association that focused on Higher Education. After a Board of Directors meeting and discussions with the Department of Commerce back in the 1990s, it was decided that the association would take on the management of the .EDU domain. That was a very strategic decision which would put our association at the forefront of the industry. We already had an association software solution in place, iMIS, that maintained records for Colleges and Universities. An extension of iMIS through a customization resulted in a solution, it allowed Universities to manage their domain name servers. The whois server for the .EDU domain was run real-time out of iMIS. I joke that I wish we would have come up with a catchy name like “GoDaddy” which was founded about the same time. This is an example, of a good customization that extended the core functionality of the association’s software. The technology allowed us to transform. The result was that the association became an integral part of the industry using technology. This was only successful through the careful customization of the association software.
Other customizations or extensions of the software that have a significant impact on the industry served, can be budgeted, and maintained, are worth consideration. Make sure that they cannot be achieved natively through configuration and can only be achieved through customization. If they can be achieved through configuration, do that first. If there is a third-party application to integrate, consider that. Only after those solutions have been exhausted, should you consider a true customization.
Many times, associations implement customizations that aren’t material to the organization or replaces functionality that already exists but is implemented to streamline the process. I see this happen often around data management, because consistency is important and data quality standards are valuable to have:
- Let’s consider if a customization that uses SQL to append a period to any middle name that is one-character long is necessary?
- What about a stored procedure that runs every night to lowercase email addresses?
These are examples of customizations that change data but don’t have any real impact on the member experience. I challenge organizations to ask if those customizations are in the “nice-to-have” or “must-have” category? I challenge you to consider that if you don’t lowercase an email address, entered by the member, that they will drop their membership or not pay their renewal because you didn’t change their data to meet your standards.
Other customizations try to automate or streamline a process that is already built into the AMS. For example, iMIS has a batch process that allows transactions for a day to be put into a batch. That batch should then be reconciled against the cash reported by the payment gateway. Then after reconciliation, if the numbers tie out, the batch would be posted. I have seen customizations to auto-approve and post batches without reconciliation. I can’t say what the motivation was of the client who did this but to auto-approve batches without reconciliation, while technically possible, is something that should be avoided. In other words, just because you CAN doesn’t mean you SHOULD implement those customizations.
The problem with many customizations is that they are 1) undocumented, 2) new staff are unfamiliar with them or, 3) staff don’t even know that they exist.
One of our clients recently implemented a configuration that allowed a company administrator to add people to a roster. When the person was added to the roster, they were given a status of “A” for active. Yet, every night we would find that the person’s status was set to “I” for Inactive. It turns out that there was an old customization that would look at the membership database every night. If a person didn’t have any history in the last 3 years, then their status was changed to inactive. There was a stored procedure that didn’t use the API’s and would change the status without recording anything in the change log. It took a while to figure out where that was occurring and the solution was to stop the automatic, customized procedure, from running every night.
Another client had implemented automatic chapter assignment many years ago. If a person had an address outside of the United States, their chapter was automatically changed. When new staff came on board, it was extremely difficult to determine what was causing the chapters to change. It turns out it was an undocumented customization that just changed the data and didn’t leave any log of what it had done.
These two examples of customizations are extremely difficult to maintain and update, especially when they are not documented. At some time, these customizations were put in place by someone wanting to streamline their processes and applied technology to do it, albeit incorrectly. Modern association software, like iMIS, have native tools to manage these types of processes without the need for customization. Over the years, we have seen clients with hundreds of poorly documented, unnecessary customizations that were written by previous technology staff. The best solution to addressing these is to not add them in the first place.
So, where do we go from here?
Associations that have dozens, or hundreds, of undocumented customizations can feel like they are in a hole that they can never get out of. There is a way forward. First, quit digging! Establish an organizational commitment to end customizations unless they are absolutely vital to the strategic vision of the organization. I talk to many association professionals wishing to upgrade their association software. They say, “We can’t upgrade because we have too many customizations.” Associations in this situation can’t take advantage of the latest features, security, and PCI compliance changes that an upgrade will support.
I have heard some organizations say, “I have too many customizations and think it is best to start over with a new solution.” To those organizations, I challenge them and ask, “If you move to a new system, are you willing to throw away those customizations and rebuild them using the out-of-the-box tools?” When they answer “yes”, I reply with, “Then are you willing to throw away our current customizations in your current AMS and start over in your current AMS?” The answer should be yes!
Each organization needs to have a game plan. I recommend starting with asking, “Can this be done out of the box with configuration?” If the answer is yes and there are no real showstoppers, then you move forward. If there is a true showstopper, then you look for a third-party extension that is supported by someone other than your staff. If there is not a solution there and there is a real showstopper to the solutions that are available, then and only if it is of strategic importance do you consider a customization. Any customization that your organization undertakes must use the rules of the software to support maintenance and upgradability in the future.
You must develop and apply a strategy to distinguish the differences between what you “can” do and what you “should” do. After that, you can start to focus on the things that will fundamentally change your organization and those things that result in true digital transformation.