Alinity logo

Subject Matter Experts & Procuring Association Management Software

Communicative Steps Your Organization Can Take

When a College or association needs to procure new software, conflicts can arise because of the various departments. It’s important to communicate everything your organization needs, very clearly, to vendors. The organization needs to be aware that they are fully responsible for knowing what they want and if what they get is working for them (through testing). An organization needs to have a single voice, preferably some form of a project manager. If too many people are communicating with the vendor, multiple opinions will be projected and the vendors idea of what your organization is seeking will get confused. The project manager is aware of all the organization’s decisions, the budget, the length of time they need for implementation, features required, etc. This is all important to know because he or she will be having the discussions with the vendor.

Subject Matter Expert

An easy way for the College or association to know exactly what they want is to discuss it with the subject matter expert of each department that will be using the solution. Different departments can include: continuing competence, complaints, accounting, registration and renewals, IT, etc. For example, the subject matter expert of the accounting department would of course be the accountant or bookkeeper. For larger organizations, each department will have a subject matter expert; for smaller ones, there might be one person taking care of a few or all departments. All the subject matter experts need to come up with transparent decisions to give the project manager to pass on to the vendor, or be written in an RFP.

Know What You Are Looking For

This is an important first step when it comes to knowing what you want in a viable software solution for your association. If you are the subject matter expert, some good questions to ask yourself and your department are:

  • What are my staff’s main complaints and bottlenecks (where workflow seems to slow down the most)?
  • If I deal with members, what are their biggest issues with applications, renewals, and managing their profile in general?
  • What are my favorite parts about our current software?
  • If I could have the perfect solution for my department, what would be it’s top 5 capabilities?
  • What kind of vendor do I want to work with? A large or small company?
  • What other vendors do I work with? What do I love or hate about them?
  • What software are other organizations using that could work for me?

After you’ve found the answers to these questions, turn them into a checklist to compare potential software to, or use our checklist which has all the features regulatory bodies and associations tend to require.

Know Your Budget!

As mentioned earlier, the project manager or lead point of contact to the vendor should definitely know their organization’s budget. Before shopping around for software that you like, figure out your budget. You don’t want to get hooked on one you can’t afford, but you also don’t want to underestimate and sell your organization short by under spending on a lame solution. Figure out a range and cut out any software outside of it.

Testing

After finding a vendor that meets your requirements, your software will need to be set up to suit your processes and workflows. In some cases that software needs to be implemented by the vendor, in other cases you may be able to set it up by yourself with some support from the vendor.  In either scenario – you and your team will need to test it to make sure that it’s configured properly to meet your specific requirements. The main point of testing is to make sure the software meets requirements and is reliable. Hands-on testing is an excellent way to not only make sure the application works, but to test its usability among the association or College. Your vendor will have tested the main functionality of the software, your responsibility is to test that specific business rules are being executed the way you expect. I.e. the vendor will have tested that their software charges late fees, but if your scenario is that it charges $25 late fees on Tuesdays and $50 late fees every other day (silly, I know, but we’ve heard of that!) then that’s where your testing becomes critical.

The hardest challenge is when you sit down in front of a new application or freshly configured application and try to “test” it. It’s a nebulous task because you may not know where to start or when you’re finished. Particularly if the software is brand new to you. Learning new software can be like trying to take a sip of water from a fire hose – kind of overwhelming!

That’s why we suggest that you have a ‘test plan’.  It does not need to be complex, but it should be a list of the main tasks that you will typically do in the application and what the expected behavior is.  A good test plan will outline a list of tests, with a little (not too much) guidance on how to accomplish each task. You can give that list (or just a portion of it) to the people who are going to test for you and have them record their results – then the task of testing a module, or a portion of the system, is not a giant daunting activity, but rather a simple checklist to go through.

Experiment with it

While testing the software, try to think of mock scenarios that you’d need to use the software for. Software developers call these “use cases“. Chances are, after the trial, that you will need to learn how to do more after implementation. Perhaps you have to know how to delete an entry, a task, or leave comments on an application. Make up fake scenarios with fake contacts (which we provide to our trial users) and mess with the software. Send an email to all the fake addresses. Assign a task to every queue. Do whatever you want. It’s the best way to get the hang of it!

It’s also important to test the software from the members’ point of view. The web interface used by members has to adhere to their colleges’ rules and regulations. The members’ perspective has to work the same as the staff’s perspective. Vendors have broad domain knowledge and expertise in software, but not in the specific nuances of each colleges’ rules and regulations. When going through mock tasks from the registrant’s perspective, a lot of these issues jump out at the staff member more quickly than they would jump out at a developer. The earlier in the process the user find these misses, the more easily and cheaply we can fix them.

The “Ripple Effect”

After testing, sometimes suggestions are made to the vendor about things they would like changed that they didn’t know they needed earlier. Depending on how accommodating the vendor makes their software, they will tweak their application to the organization’s liking, usually for a price. Unfortunately, modifications can also lead to the “ripple effect.” The ripple effect is when a change has been made to an application and it ends up affecting other areas of the software (like a water ripple), usually causing other problems. This means the vendor now has to go through regression testing which is testing for new bugs, and if there is any, they need to take more time fix them and make sure problems do not occur later on. Colleges and associations needs to realize fixing these little changes may not have been included in the vendor’s quote.

The best advice vendors want organizations to know, and yes it has been repeated earlier in this post, is that it is your responsibility to know what you want and let us know. No matter what vendor you choose, knowing will save you time and money. If you are currently seeking new software, which is likely why you found this blog post, please check out our software procurement checklist! Not only can you use it as criteria for license management or association management software, it can be used as a checklist for subject matter experts to refer to when discussing what they want in their “dream” software. Click on the image below:

 

en_USEnglish