Organizations choosing enterprise-level Association Management Systems (AMS) likely do so for a range of reasons. They know they’re getting a product with a rich feature set and all kinds of configuration options. They know they’ll have a greater deal of flexibility. But, likely most important, is the system can be customized to their need.
Unfortunately, customizations are a double-edged sword. On one hand, they allow the organization to completely mold the AMS to their business needs. On the flip side, customizations require extra maintenance, which is work. With that in mind, here are a few items to consider when considering a customization.
Make sure it’s a business need
When staff says, “We need the system to X because that’s how we’ve always done it.” SIRENS should start going off. Often old processes are built around an old AMS, and if you really liked your old system, WHY DID YOU GET A DIFFERENT AMS?!? Customization should always be driven by either a business rule or business need. Business rules are usually listed in the by-laws of the organization, and business needs are a feature that will help deliver against the business goals of the organization. Requiring staff to draft up a business case for new customizations is not excessive. If nothing else, staff willing to put in the effort to come up with a business case obviously have a little conviction behind their customization request, while the folks who think it’s too much work will likely figure out how to fit their processes within the baseline.
Clearly define purpose
As part of a business case, there should be an understanding of “WHY?” a customization is needed. Too often customizations focus on how they will work, with no conversation about “why.” Having a “why” clearly defined helps ensure the effort always matches up with the purpose. If you just focus on the how, you can end up 100 hours into a development project before you know it, and if the customization only helps one person save 8 hours once a year, you’ve made a mistake. Even if you do need the customization, there will inevitably be opportunities for scope creep. With a defined purpose any scope creep items you can ask, “Does this help address why we need this customization?” If the answer is no, then keep it out of scope.
Build for flexibility
Most customizations are built to fix an issue now. Which is good — until you’re no longer in the now. In time, you will find yourself painted into a corner.
As part of the design process, try to identify input values. These could be inputs into formulas, text descriptions, drop down fields, or any other number of values. With each of those inputs, make sure the values are captured in an area that is easy to update without having a developer get involved, either in a control panel, system option, or some other feature that can be edited, instead of having the input value hard-coded into the customization.
Think of a spreadsheet, where you have to multiply a bunch of values by 20%. For each of those fields you could go in and type 20% into each field, but then if your boss comes back and says, “Actually, we need to do 25%,” you’re now stuck finding and replacing each 20% in your spreadsheet. Instead, what you want is to type 20% into one field, then everywhere in your spreadsheet where you multiply by 20%, just reference that field. That way when you need to switch to 25%, you only have to make one change.
Granted, building for flexibility usually requires a little extra work, so balancing the right amount of flexibility against your budget is a per-project judgment, but some are always better than none.
While everyone wants a perfect system out of the box, most enterprise level associations will inevitably need to customize. Being strategic, purposeful and flexible with those customizations will serve you well in the long-term success of your organization’s AMS.