You’ve probably seen questions like these in ASAE Collaborate or another association/nonprofit forum:
- We’re looking for a new AMS/CRM. Do you have a recommendation?
- What are the pros/cons of [AMS/CRM brand]?
- Does anyone have an RFP they can share?
Before you ask people for recommendations, you must know what your organization needs because the software that works for them may not work for you. You can’t use another organization’s requirements or RFP to find the right system for your unique needs. Sure, those documents can offer ideas about what to investigate, but the only way to ensure you’ll get software that meets your organization’s needs is to spend time gathering and prioritizing requirements.
Why requirements deserve more time and attention than they usually get
Requirements gathering—defining what the software must do for your organization—is the most critical phase of a new AMS/CRM project. If you don’t determine precisely what functionality you need—and ask for it—there’s no guarantee your software will do what you want and expect it to do.
Even if you had a dozen conversations with a salesperson about your organization’s needs and your current software’s shortcomings, you can’t rely on their notes as your requirements documentation. Your team must go through the process, so you’re confident the list of requirements you provide to potential technology partners is accurate and complete.
The essential role requirements play throughout implementation
Requirements are essential when you’re researching, evaluating, and selecting software. Requirements bring necessary method to the madness of system selection. They help you determine which software is in the running, narrow down your list to a few finalists and score those finalists on how they meet your requirements.
Your implementation partner relies on your requirements too. After further discussion with your team, they take your initial requirements and document your functional requirements, which keep your project on track. Their documentation ensures everyone is on the same page, especially when you have to reprioritize requirements during the project. Requirements are a major factor for a successful AMS/CRM implementation.
Who’s involved in requirements gathering
This is not a solo venture. Anyone who will use the new software or use the data stored in or delivered by the software (or a representative of these different groups) must be involved in the requirements process. These people are your project stakeholders—as users, they have a stake in the project’s success.
By getting stakeholders involved in the project from the start—during the requirements phase—you are more likely to earn their buy-in and trust, and, in return, they’re more likely to adopt the new software enthusiastically. During the requirements process, you need insight into processes and desired outcomes, old system shortcomings, and new system functionality. Being involved like this will give them a sense of project ownership, which will come in handy later during testing, training, and adoption.
Every project also needs an executive sponsor, someone who has the authority or influence to allocate a budget and arrange staff cooperation. An executive sponsor can ensure that the people who need to participate in meetings will not be held back by department heads who prefer to limit the time their staff spends elsewhere.
The project manager takes the lead on the requirements process unless you’ve engaged an experienced consultant to work with you. A consultant has the business analysis, project management, and technical expertise you need for this critical project stage. They bring an objective perspective to the work; they have no agenda except to get you the best system for your needs.
Because of their experience working with associations/nonprofits, each with their own unique processes and practices, consultants can guide discussions about workflow and help you improve existing processes based on best practices. These decisions can be as impactful as the software you select. Since requirements are a prioritized list of needs, not a wish list, a consultant can help you determine the difference.
How requirements are gathered
Requirements gathering occurs during stakeholder interviews (individual and group) where business processes, pain points, data sources, and reporting needs are discussed. The consultant develops user stories to illustrate the functionality needed. Once everyone has been interviewed, requirements are prioritized and documented.
After you make a selection, you meet with your new technology partner’s implementation team to align your initial requirements with the chosen software. They document functional requirements to guide their design and configuration work. Together, you also analyze legacy data sources and validate (or adapt) business processes.
An unexpected bonus: requirements magic
During the requirements phase of the project, your team figures out what you need the new software to do—an essential task for ensuring the success of your new AMS/CRM. But that’s not the only positive outcome of the requirements process.
During requirements meetings, staff learns about the goals and challenges of colleagues in other departments. They hear about the desired results for the project and how they align with the organization’s strategic goals. They question, evaluate, and revamp business processes and organizational culture benefits from the cross-departmental collaboration that begins during the requirements process.
Change management also starts here. Staff expectations are managed since the people involved know what’s in the project’s scope and what’s not. As project champions, they have a sense of ownership because they know you relied on their expertise to select the new CRM or AMS.
Are you ready to talk through your requirements? Do you need help figuring out where to start? Contact Fíonta—we can help your team define requirements for software that will deliver your desired outcomes and exceed your expectations.