Would you like to leave behind a legacy that will have people at your association talking about you for years? Make sure it’s not this kind of legacy…
I once heard an association COO talk about the time and money his association sunk into an AMS customization—more than 500 hours on a customization that he says, a few years later, wasn’t even necessary. And now, he’s handcuffed to an outdated system they can’t afford to update—or abandon.
What’s the difference? AMS customization versus configuration
When you talk about customization to association technology professionals and consultants, the stories keep coming. It starts sounding like a group IT therapy session. You won’t find too many customization fans among those who have been around the implementation block a time or two.
If you’re new to software system selection and implementation, you’ve probably seen the terms ‘customization’ and ‘configuration’ and wondered about the difference.
Configuration involves modifying software without having to rewrite the core programming code. For example, you can configure (modify) drop-down menus, add fields to a form, or change field names without having to call in a programmer. Software providers have noted where clients frequently want to modify specific system features, like menus or forms, so they build tools within the system that allow clients the flexibility to configure (modify) those features themselves.
With customization, a developer has to rewrite the programming code for the benefit of one client so they have the unique functionality or feature they desire. And sometimes that customization can take more than 500 hours of the developer’s time!
To illustrate the difference, imagine buying a home in a new subdivision. The builder offers a few different countertop, cabinet, and flooring options (configurations) for the kitchen. These modifications won’t ruin your budget or slow down the schedule. The builder expects homebuyers to take advantage of them. These changes don’t affect the kitchen’s design or blueprint.
However, if you want to move the sink to the other side of the room or add a pantry, that’s a different story. Now the builder has to go back to the architect and designer and ask them to change the blueprint (code) so those customizations can be added. The builder also has to make sure the new plumbing, electric, and HVAC (features and functions) fit in with the rest of the house. This customization takes more time, involves more people, and therefore costs much more than merely selecting a different type of countertop (configuration).
Why do associations opt for customization?
Despite the additional time and money involved, some associations believe they have to customize the new system. Why is that?
5 reasons associations might customize software:
- They have the impression that’s the way things are done. It’s been about a decade since they purchased their existing system. Back then, customization was more common with systems owned and hosted on premise. Now, SaaS solutions are more common—and they’re a different animal altogether. Sometimes customization isn’t even possible because the software is used in a multi-tenant (shared) environment.
- Associations resort to customization because the new system isn’t flexible enough to configure. For example, they can’t restrict fields in member records to specific member levels and, therefore, avoid future data integrity issues, or they can’t change the order in which fields appear. In many systems that type of modification is a configuration, but in some, it might require customization.
- Customization sometimes results from poor requirements management. Instead of distinguishing between must-haves and nice-to-haves, an association considers everything as a must-have and the system has to be customized to meet those needs. In reality, if you can get 80% of the functionality you need, that’s a home run in system selection.
- Too often, users insist on functionalities that require expensive and time-consuming customization, and guess what happens? Those same people rarely use those ‘must-have’ functions. We live in a world where we’re used to having it our way and creating our own adventure—that can spell trouble when selecting new association software.
- But, the most common reason for customizing a system is the desire to preserve familiar business processes. Nobody likes change but sometimes change is the best option. Encourage your colleagues to be open to suggestions about adopting new business processes or adjusting existing processes. If the square peg (system) doesn’t fit into the round hole (an existing process), don’t spend time and money recarving the peg (system). Instead rework the round hole (process): square it up so it fits the new square peg (system).
System implementation is a change management project. Expect people to resist change—that’s only human. Anticipate who will resist change and tap their expertise throughout the project. Try to get them invested in the project and the outcomes you expect.
The dire consequences of customization—and what to ask before you choose that path
Know what you’re getting into when you opt for customization.
Customization is a budget buster. Rewriting and testing code takes time. Your association pays for that, and you won’t only pay once—as you’ll soon see.
After implementation, you may not get the customer support you need because the vendor’s help desk might not be able to answer questions about customized features. If you plan to customize software, ask the vendor about the extent of the support they’ll be able to offer. Better yet, ask a few clients who have customized similar features about the support they receive. Also ask them about their reasons for customization and whether, looking back, they would take the same approach.
Worst of all, customization can throw you off the software’s upgrade path. If you try to implement upgrades so your association can take advantage of new and/or improved functionality, you take the chance of ‘breaking’ your expensive customized features. All custom elements of the software must be reapplied to see if they still work with the upgrades. If they don’t, you have to pay for more programming to retrofit the customizations every time the vendor provides a new release/version.
Usually when a project’s budget runs out due to customization costs, documentation is one of the first things to go. Upgrades become even more challenging when customizations haven’t been documented. Down the road, when it’s time to upgrade, you won’t have a record of how your system was modified.
Every technology consultant has come across organizations that stopped upgrading a system because earlier customizations have made the upgrade path too complicated and costly to pursue. But, deciding not to implement upgrades is a risky decision. Upgrades often include new security settings to keep your system and data safe from cybersecurity attacks. That’s why some associations want to replace their existing system—because the system has been customized beyond the point of return.
In rare, exceptional cases, customization is necessary—but make sure what you gain by customization far outweighs the potential risks and costs. Go into customization with eyes wide open and understand its impact on the implementation, support, maintenance, and lifetime cost of your system.
You decide not to customize your association software—what are the alternatives?
System selection is the perfect time to take a fresh look at existing business rules and processes. Rather than customizing a system, see if you can reconfigure the conflicting business process. A business analyst with experience in association operations and technology can help you imagine and design new processes and workflows.
Choose a flexible system that allows your team to make configurations without the vendor’s assistance. Ask to visit with clients who have configured the system in ways similar to your requirements. Find out what they thought of the configuration process and ask for a demonstration of that configured functionality or feature.
Give new processes a chance. Make a decision to launch the new system with as much baseline functionality as possible, that is, with the least amount of additional configuration and customization on top of the baseline system. Reserve 20-30% of your budget to further refine and configure the system after you’ve used it for three to six months. You’ll be in a better place to judge what’s truly workable.
What if you don’t want to customize but the baseline system doesn’t include configuration for a feature you’d like? Talk with the vendor about your needs. Is this functionality something other clients might need as well? Most software vendors have a process for clients to request new features. Make a business case for it—and it may get on their product roadmap.
Leave a legacy that helps people love their AMS (and maybe even you, too)
Don’t complicate your life with customization. And, don’t complicate the lives of those who follow in your footsteps. Avoid customization and you’ll avoid future headaches.
Best of all, you won’t have to budget for expensive, time-consuming rewriting of code every time there’s a new release. You’re not leaving a challenging legacy for future staff and tying their hands to an unwieldy system.
You’ll have the flexibility to download upgrades and integrate with the software of your vendor’s partners. And, as the vendor improves the system to keep up with market needs, you can keep up too.
Even with all this well-heeled advice, the customization vs. configuration dilemma can be confusing. Start your project off right with a detailed requirements analysis—our free whitepaper will guide the way, and may even be the secret to your sanity.
