The following article was transcribed from a teleconference presented by Network for Good on April 15, 2008.
When you boil down the database selection process, there are five basic steps:
- Convene the right team.
- Specify your needs and priorities.
- Secure funding.
- Identify a pool of potential vendors.
- Test vendors against your needs.
- RFP/RFI
- Scripted demos
- Usability testing
- Reference checks
- Full-cost proposals
1. Convene the Right Team
First, convene a group of people who will select the database. The team should consist of subject matter experts in the areas that the database is going to address. Since we're talking about a donor database, that's usually direct mail, major gifts, grant writing, gift-entry, and IT staff. You need to get input from the people who will actually have their hands on the keyboards, getting the donations in, running those reports, etc.
Selecting a database is not an IT decision. It is a business decision about how you're going to run your nonprofit. Techies should be included on the selection team so they can advise you on the standards that are appropriate for your organization, but it's not a technical decision.
You also need to realize that while you're trying to get input from everyone, you may not be able to satisfy everyone in this decision. You're probably not going to be able to afford, or necessarily even find, a database that will do everything the team can possibly imagine.
So part of the exercise is going through a prioritization exercise so that you know which needs are most important.
2. Complete a Needs Assessment
What are your requirements? What's working well now? What can you not give up? And what's wrong now? What are goals in doing this project? What are you trying to fix? Maybe it's not something that's broken now, but it's something that, as you consider the growth the organization is going to experience, you think will become a problem in the future. For example, you've never done major-gifts fundraising, but you're going to start within the next year or two and your current software won't support that activity.
Here are the questions to ask yourself and your team:
- Is software really the problem? You might have the right database already, but the people who were trained have all departed the organization and no one has been trained since. Or the database may have modules that can do what you need but you haven't purchased them. Or your organization might have mis-configured the database-it can actually do what you need but it's not set up properly. Or perhaps the wrong people are managing the database.
If software really isn't the problem, new software isn't going to make your life any easier. So first you need to decide whether this is a truly a software problem, or a people or process or policy/procedure/communication problem. - What do you really need? You need to distinguish wants from needs. A true need is a single requirement that will disqualify any system that lacks it, regardless of price or other attractive features. For instance, if you're a Macintosh shop, Mac support is mandatory.
Those features that are not mandatory need to be prioritized. When you look at systems, you should first eliminate those that don't meet your mandatory requirements. Then you can and focus on those that meet most of your top priorities.
- What can you afford and support? There may be a database out there that can meet every one of your requirements, but will it cost vastly more than you can spend? Will it require new staff people to support it-positions you can't afford? Or will it require a higher level of technical skills than your staff possess?
3. Secure Funding
Depending on the database, software may be the smallest part of your purchase. As databases become more complex, you often need other things to go with them. For instance:
- A new server to run the software on
- Updates/replacements for desktop hardware
- Upgrading your network so you have a fast-enough connection
- Training for your staff
- Converting your data from your old system to the your new one
- Developing new reports
- An annual or monthly fee to continue using the software (unless it's a free piece of software to begin with)
There is set amount for how much you should spend on your database. It really depends upon your needs. But based on the clients I've worked with, I've generally seen a starting price for a database at approximately a quarter of one percent (0.25%) to one half of one percent (0.5%) of the organization's annual operating budget-not the fundraising budget, but the complete operating budget. So an agency with a million dollar operating budget might start looking in the $2,500 to $5,000 price range (not including conversion, training, hardware, etc.). They might be able to spend less; on the other hand, if their needs are complex they might have to spend quite a bit more.
4. Identify a Pool of Potential Vendors
Now that you know what you're looking for and have a ballpark budget in mind, you need to identify a list of potential vendors. If you are part of a network of organizations that do similar types of work, that's usually a great place to start. There might also be deals between your national headquarters and vendors or deals between other chapter offices of your organization and vendors that can save you money. Even if you're an independent group, you can find out what other similar organizations are using.
You can also ask on general purpose lists, such as TechSoup and Charity Channel. Talk about your specific requirements so that you hear from comparable organizations.
Try to find vendors that have experience working with organizations that are similar to yours, unless you are willing to take risks. Sometimes it is completely justified to take a risk on a vendor who has never worked with your kind of organization before because their technology meets your needs, they inspire confidence, and they are interested in getting into your market. They may be willing to give you a great discount in order to prove themselves in your market. But only accept the discount if it is software that looks like it's really going to meet your needs.
5. Test vendors against your needs
- RFP/RFI. Issuing a Request For Proposals can help you identify vendors. If you can ask clear, unambiguous questions that can be answered with a yes or a no (and maybe some amplifying text), an RFP can be helpful. Recognize that any question you ask the vendor should be a question that you can score a response to. So a "yes" answer has to mean something specific, and that gets points. A "no" means the opposite and gets no points. A well-written RFP can help you identify vendors who wouldn't have been on your radar otherwise, or help narrow the field when you have too many vendors to evaluate in-depth.
However, it is difficult to craft an RFP that will accomplish this goal. Also, some vendors do not respond to RFPs. Depending on your needs, you might be able to get the information you want with a short Request for Information (RFI), or even a phone call. RFIs are good for answering basic, factual questions.
- Scripted demos. You are really only going to hold demos with a few vendors-three or four is usually the ideal number. The goal in holding demos is to compare apples to apples between the different vendors. It's ideal to use an on‑site demo whenever possible, which means that the vendors come to you.
If some vendors can come to you and some can't, I prefer to do Web demos with everyone. Otherwise, the vendor who comes to you has an unfair advantage over those that don't.
The most critical step is to use a script to tell the vendors what they need to show you to prove that they can meet your requirements. The demo should focus on those areas that emerged as the top priorities in your needs assessment.
Have everyone on your team rate the demos (usually a 0-10 scale with a space for comments). These ratings should not be anonymous. For instance, it's important to know whether it was the gift-entry person or a program manager who rated a system poorly on gift entry features. - Usability testing. After the demos, ask for access to a demo copy of the system. This could be a disk the vendor sends you, or they could make the system available to you online.
As with your script, make a list of things that you want to test. You will then test the system(s) that did well in the demos. You might only do this with your top vendor, or with every vendor that demoed. For instance, you might test creating new records, changing addresses, linking related records, and entering various kinds of gifts. Ask for some coaching from the vendor so you won't be fumbling around blindly (although you will certainly learn things about a system's usability by fumbling around.)
You should rate these tests just like you rated the RFPs (if you used them) and demos. Everyone will fill out a rating form and you will see which systems tested best in actual use.
- Reference checks. As with usability tests, you might only check references on your top vendor, or on every vendor that demoed. Talk to clients about whether the system really is as easy to use (or as complicated and confusing) as it looked.
You will probably have a list of questions that arose during the demos and your usability testing. You'll also have general questions about the vendor: Did they install the system on time? Did it cost what they told you it would cost? Do they answer your questions promptly? Do they introduce new bugs every time they upgrade the software?
You need to talk to enough references to distinguish between bad clients and bad software. So if you hear something from just one site about problems, it could be that their staff wasn't trained properly, or they didn't configure the software properly, or they outgrew the software but can't afford to change it.
Approach reference checks like reference checks for hiring someone: you may live with this database longer than you will live with most of your employees. It's critical to ask detailed questions about the software and vendor.
Optionally you may want to visit client sites that are using the software and find out how it works in real life. That can be incredibly educational. If you take this step, look for organizations similar to yours in size and complexity.
- Full-cost proposal. You may have received a cost estimate when you first talked to the vendor. As some point, you will need to get a detailed cost proposal. It should include the software, training, conversion, and ongoing maintenance fees. Particularly with software that is sold by module, you really won't know the final cost until you have a conversation with the vendor and say, for instance, "We think we can do without the volunteer module. We can keep tracking that in Excel or in our FileMaker database. But we really need the events module."
Adapted from Robert Weiner's "All You Need to Know about Choosing a Donor Database" presentation. You can listen to the complete presentation or read the transcript by clicking on the presentation title above or the "related article" link below.