October 23, 2014
The road to a bad AMS implementation is paved with good intentions.
Many of you are considering changing out your association management software (AMS). Some of you have already selected a vendor and an even luckier few have begun implementation. All of you are vulnerable to what I call The Requirements Trap.
In order to understand how insidious and dangerous this dysfunctional state of affairs is, you need a bit of background, some color. When you select an AMS vendor, you’re not really buying software - you’re solving a problem. Members need to be able to renew online. Staff need real time access to data. Some inefficiency or another needs to be corrected. Essentially, we need a Unified System, a solution to a problem.
This nuance seems obvious once stated but is often lost in the complexity of the AMS implementation. So I’ll say it again: When you purchase an AMS, you are not buying software. You are buying a solution to a problem. Put that in your pocket and hold on to it – well come back to it later.
As an AMS vendor, we manufacture and sell software. Most of us that have manufactured good software will find that our product comes pretty darned close to working for a lot of our customers. But the idiosyncratic nature of associations means that invariably, a gap will exist between the product we’ve built and the problem you’re trying to solve. Sounds reasonable, right? OK… stay with me.
The key problem is that when your staff recommends the AMS, when you take it to the board, and when you eventually make the biggest technology investment that you’ll likely make in an AMS, no one is drawing a distinction between the software and the solution. The thinking goes something like this: We gave you $XX,000, and we expect a system that “works”. In this case, “works” actually means “solves our problem”. And there, ladies and gentlemen, lies the rub.
Larger associations (100 staff and higher) typically have IT managers and savvy professionals on staff that understand this and formalize the process of gathering requirements, defining on paper what “works” means. Smaller associations have requirements that are often pliable enough to fit into the package they buy. But the mid-market – oh, the mid-market – cannot contort themselves into an off the shelf package but often may not even have an IT professional on staff. If they do, it’s likely they were unwittingly conscripted into the role because someone got wind that they could install Windows without the PC catching on fire, and they inherited the position with no real experience implanting technology systems.
And so enters The Requirements Trap. The Requirements Trap happens because you (the association) have an idea, be it half formed, of what “works” means, and no means or expertise to explore and crystallize it in a way that is actionable by the AMS vendor. The AMS vendor relies on the point of contact for requirements, but the point of contact is not trained to surface them. And so the vendor implements the software to the best of their ability, and runs through their own process, which, while very good, may not fully solve the problem you were intending to solve.
The big, hairy, obvious problems are tackled because they are easy to spot - online membership renewals, financial integrations. etc. The problems that cause the snags lie in the subtle requirements, because often those are not obvious, and many of those emanate from processes that require internal deliberation that never happened, because an AMS system never existed.The big, hairy, obvious problems are tackled because they're easy to spot - the snag is in the subtle ones”
The very first AMS I wrote in 2002 was launched a year later. I was 23 and stupid. Yep – stupid. I remember the champagne I drank on the day it launched. I remember the key goals of the executive director. I remember the automation, web self-service and integration all worked. Everything seemed fine, until the auditors showed up.
It turns out that the system I wrote did not have adequate reporting in order to withstand a financial audit. Because this is a family blog, I will most definitely not repeat what the Director of Finance said to me about my system during the first audit, but suffice it to say it was not a glowing compliment on my programming skills.
But how was I to know what was required for an audit? How did I know what reports they needed? No one even told me that an audit was done or how it worked!
The response? “You never asked us!”
And that was my first introduction to The Requirements Trap. The Requirements Trap happens because of an impossible expectation that an AMS vendor will be able to dig through and extricate all of your requirements, half-formed or otherwise, negotiate your internal politics, drive consensus, and have the moral authority to force compromise.
We don’t wear our tights and capes to kickoff parties. There are activities required for a successful software implementation that simply cannot be outsourced to the software vendor.
The way to get out of The Requirements Trap is to ensure that a qualified, empowered project manager is managing the implementation on your side. Let’s break down what that means.
“Qualified” means she has a firm grasp of not just technology, but also of your business processes. What she doesn’t know, she must feel comfortable asking.
“Empowered” means the she is backed by the executives of the association, and everyone knows it.
I’ve seen implementations where the administrative assistant is in charge. These are doomed to fail, as when she tells the membership director that they need to compromise on a requirement, she is quickly shut down. The project manager must then have moral authority - when she speaks, everyone else listens. When a hard decision is made, she is respected. Of all of the reasons why your AMS vendor cannot fill this role, moral authority is the biggest. When an AMS vendor pushes for compromise, it is met – rightly so – with suspicion. When your internal staff member does it, it’s a lot easier to hear.
Many of you will not have this person on staff – that’s fine. Hire her. I see so many associations hire a consulting firm for selection and then wing the implementation part. The implementation part is where you need the help!
Perhaps the most important part of building software is deciding what needs to be built. If you build the foundation for a 2 story house, and it turns out the house will have 4 floors, you’re probably having a bad month. Yet this is the most overlooked step! Developers (and take it from me, I am one) tend to want to just jump in the code. It’s what they know, it’s where they feel comfortable. But without proper requirements gathering, there’s a high probability the wrong thing will get built.
It’s the same with implementing software for your association. You have, in your head, an idea of what the software should do. It’s half-formed, but it’s there. Jim, your developer, has his own idea. You figure Jim knows what he’s doing. But Jim can’t know what you expect.
If you skip the requirements step, there is a 99.9999% chance the software Jim writes will be very, very different from what you need. Here’s why:
Your thoughts are half formed – you have dreams of what you want. Jim has half-formed thoughts too. But yours are process/organization driven – what can we accomplish? And Jim, being an engineer (when you’re a hammer, everything looks like a nail) has technical thoughts – what can this thing do? You’re assuming that Jim, being the tech guy, can fill in your half formed thoughts. This is a bad assumption. See, Jim can build things, but Jim can’t read your mind, and can’t complete your thoughts.
And so when Jim does deliver the wrong thing, Jim will say, correctly, “You never told me you wanted that!” And you will say, “You never asked! You’re the engineer, it’s your job to ask these questions, you’re the tech person – how should we know?” And he’ll respond, “I can’t read your minds!” And you have the start of an acrimonious relationship. Jim will do his best to fix the first hole, and the second, but by the sixth or seventh scope creep, he feels like you’re taking advantage of him, and you’ve got big problems.
The moral of the story is that requirements gathering takes specific skills. Requirements gathering requires the skill of listening. Sometimes, you the client are saying 20 things, but a good business analyst hears 2-3 things. Good business analysts can also challenge requirements by asking – why? Why do you need to get emailed every time a person changes their address? So you can update it in your database? Well you don’t need that anymore since it’s one central database.
Business analysts and AMS companies have seen hundreds of these conversions, and have become very adept at knowing what requirements are real and what should be pushed back on. Jim just knows you. The net effect is you all are learning about the wheel together. The only thing is, if he leaves, Jim takes those lessons with him, but you – you’re stuck with them.
Requirements gathering is an essential part of the process of implementing new technology. You’ve got to know what you really, truly need in a system, what has to happen in order for the solution to solve the problem, and have to have someone that can see this process all the way through. Avoid The Requirements Trap and make sure your implementation goes off without a hitch by heeding the advice in this cautionary tale.