This post, The Basics, is part 1 in a series of posts about software selection. Next week we will evaluate the software itself comparing solutions from Blackbaud and Salesforce.

First, The Basics: Is your organization considering a move to a new donor database? For many nonprofit organizations this is one of the most important technology decisions they’ll make, and a decision they have to live with for many years to come. Well, don’t feel like you have to go it alone. Here are a few things to consider as you get started:

Define What You Need

Take time upfront to work with end users and define what they need from the new system. What are they looking for to enable their fundraising strategy? What are the current and future fundraising needs?

A solid understanding of the business direction will help ensure IT alignment. Also consider the current system environment. Are there areas of the business that are unsupported today (i.e., done manually) that need to be part of the new solution? What functionality is missing today? What are the pain points? What works well today that should be preserved going forward? When doing this exercise consider going functional area by functional area and defining the requirements and sub-requirements of each section.

Fundraising capability models can help facilitate the process. Defining the goals and objectives now will help justify the required investment. And these same details can be used to help measure success after go-live.

Not All Requirements are Created Equal

As any users will tell you – not all requirements are created equal – they just might not say it that way. The user may say, “I can’t do my job without that.” “Oh, it does that, we don’t do that.” And so on… That’s why it makes sense up front to define a priority for each requirement. What are the essential functions end users must have (i.e., must have)? What functionality is preferable and should be available on day one (i.e., should have)? What are the functions that are useful but users could live without if they had to in order to get the critical pieces in place (i.e., could have). This prioritization can be used to help focus the search the solutions as well as facilitate the analysis and ultimately decision making process later in the project.

Define Your Vendor Solution Short-List

So now you know what you need and how important it is to your organization – what next? It’s time to pick a short-list of solutions for consideration. But how? For many organizations it starts with looking at their current vendor and solution and considering the options.

Are we happy with the current vendor (even though the current software doesn’t meet all or our needs)? Should we consider upgrading to the latest version of their product? Perhaps they’ve made a major change to the platform (e.g., the solution in now available in the cloud). Or maybe the vendor’s product roadmap has evolved and they have newer (and hopefully better) options available.

Other things to consider include: What are similar organizations doing? Where is the industry heading? What was that vendor/solution we saw at the industry conference last month? Frequently, organization will consider several options from multiple vendors to ensure a sufficient coverage of available solutions.

S/He Shoots, S/He Scores!

This is where the rubber meets the road. And there really is no wrong way to go about this – as long as the functionality available (or not available) from each short-listed solution can be fully analyzed and understood.

Some organizations do formal vendor demonstrations. Each vendor gets a day/time slot to show what they can do. Some will get access to a test system to kick the tires. Others seek the advice and guidance of vendor agnostic third party consultants.

However you approach it, this exercise is about taking the prioritized requirements from Steps 1 and 2 above and evaluating them for each short-listed solution. The evaluation needs to be a measure of how well the functionality in the system satisfies the requirement (e.g., fully meets, partially meets, does not meet, etc.). The granularity (i.e., number of choices) and wording should be meaningful to the organization based on some agreed upon definitions.

Decisions, Decisions….

So how do you bring it all together? There are several options and the answer could depend on how your organization makes decisions. Some organizations are analytical. For those, a more quantitative option can be effective. One approach could be to assign weights to the requirement priorities and evaluations and calculate a score for each requirement.

With this approach the software package with the highest overall score is the winner. Not an exact science but grounded in a standard method.

Other organizations may prefer to use a more qualitative approach based on opinions or input from a selection committee or assessment resources. This approach could be facilitated by giving each participant a vote and asking them to explain the reasoning behind the decision.

The important point is to make an overall evaluation of the results and choose the solution that best fits your needs.

At BrightVine, we work with our clients to provide software selection services and can assist your team with their selection, implementation and more. Learn about our services today. Contact the team at BrightVine Consulting for suggestions and options to consider.