Lessons Learned

As a Software Engineer on the Nimble AMS Product team, I’m constantly working on Nimble AMS features, enhancements, testing documentation, and other product areas. Every now and again, product engineers assist with client implementations. This helps us remain connected with how Nimble AMS is implemented and received by the customer. Earlier this year, I had the great pleasure of implementing Nimble AMS for one of our clients with my fellow Nimblers.
​
Here are some Lessons Learned and Re-affirmed from that experience.

Associations have many things in common. They have members, hold conferences at various venues, sell merchandise, and conduct other business too. While many of these activities are similar, each association does them their own way. During implementation, Nimble AMS is customized to fulfill the association’s way of doing things, which it does easily through administration and customization.
One common customization is pricing. While Nimble AMS provides many pricing options already without customizing, there are times when other pricing needs to be implemented. Our client required specific membership tiered pricing based on a member’s Annual Revenue Level (ARL).
Here’s a contrived membership tiered pricing example.

                      Annual Revenue Level (ARL)                            Member Price ($)
                             1 –   9,999.99                                                   100.00
                 10,000.00 – 99,999.99                                               100.00 + 1% of ARL
               100,000.00 – 999,999.99                                             100.00 + 2% of ARL
 … Other Pricing Tiers … 

To implement this, a new “Member Dues Price” formula field was added to the member record that looks at the member’s Annual Revenue Level to calculate the member’s dues price. Here’s what the contrived formula would look like

          If (Annual_Revenue_Level <       10,000,    100.00, 
          If (Annual_Revenue_Level <     100,000,    100.00 + (Annual_Revenue_Level * 0.01), 
          If (Annual_Revenue_Level <  1,000,000,    100.00 + (Annual_Revenue_Level * 0.02), …

Now with this formula created, whenever the member’s Annual Revenue Level is entered on the member’s record, the membership price will be calculated and instantly shown. Next, the Nimble AMS order processor was augmented to use this “Member Dues Price” field to allow the correct membership price to be calculated when a member joins or renews their membership. In short order, our client’s membership tiered pricing was implemented and ready to go.

​Now, if the pricing changes, an administrator can simply change the “Member Dues Price” formula field and the changes will be reflected throughout the system without any coding changes and without requiring any engineers. Now that was easy!

During our client’s go-live week, I had the great opportunity to be on-site with a few of my fellow Nimblers. While there, I met many great people and was able to observe how they used Nimble AMS. Here are some of my observations:

• Nimble AMS greatly simplified and eased the amount of work staff had to do. This saved time and enhanced capabilities allows staff to focus more on their members and ultimately to provide even more benefits to them.
• The staff were very enthusiastic to retire their old system and start using Nimble AMS. They even held a “Memorial” service for the old system and an after party. Don’t believe me? Here are some photos. For more photos, check out ASCRS Nimble AMS Launch Photos, MSTA Nimble AMS Launch Photos, and LeadingAge Nimble AMS Launch Photos. ​

Automatically executing a Test Suite daily is priceless during development / implementation. Daily regression testing during development / implementation helps identify things that broke since yesterday.
For example, if Feature A was working yesterday and isn’t today, it’s easy to track down what changed and resolve the problem, especially when using Source Control. With the change(s) that caused the issue originating within the last 24 hours, the change(s) are fresh within the developer’s mind so time isn’t needed to remember or figure out how things work.
​
This ultimately leads to better quality software developed in less time.