Ten Common Mistakes in Selecting Donor Databases

Age : 45 Joined : 08 Mar 2008 Posts : 1850

This article is courtesy of Idealware, which provides candid information to help nonprofits choose effective software. For more articles and reviews, go to www.idealware.org.

How do you choose a donor database that will support successful fundraising? The software is only half the story. Fundraising technology strategist Robert Weiner addresses ten common mistakes that can prevent you from selecting the right database and managing it effectively.

Picture, if you will, two nonprofits. The first has a donor database that is full of bad data. Donors are getting the wrong receipts or no receipts at all. The organization cannot use the database to plan its fundraising strategies or track its effectiveness. The few reports it can get are useless. Staff members complain that no one trained them, and they get no technical support. For obvious reasons, they hate the system. The second organization loves its database. Its data is clean, its donors get timely, accurate mailings, the organization has a good handle on its fundraising activities, and staff get the reports they want. New personnel are trained on the database before they ever log in, and someone on staff helps them resolve any problems and questions that come up.

Both nonprofits are using the same software package.

How can this be? Perhaps the first organization has outgrown its old system. But it is quite likely that the organization never had the right software to begin with, and then proceeded to use it incorrectly. It made a series of bad decisions and has been struggling with them ever since.

How do you avoid this fate? Selecting and managing a donor database is never easy, but if you avoid the mistakes on this list, you can start out on the right foot.

1. Letting Techies Make the Decision
In the early days of computing, programmers created all donor databases. Their role was to turn fundraising concepts into software programs. But since most fundraisers did not (and still do not) want to be involved in the detailed decisions and testing required to design a database, programmers usually drove the project.

Although the market for donor databases has changed significantly over the past three decades, techies still make many of the purchasing decisions. However, few techies have experience with fundraising. This makes it critical to get input from the people who will actually use the database. You don't need to include every staff member, but you should get input from all levels of the organization (management, departments, end users); fundraisers from all areas of development (direct mail, grants, major gifts, corporate relations, and planned giving — if you have all of these); and other staff who may be impacted by a new system (administrative and data entry; those who create and run reports; other departments that provide input or use fundraising data). The techies should be there to advise on whether a system will fit into your organization's technology strategy and be supportable in the long term, but they should not make the final decision.

2. Wishful Budgeting
Before you go shopping for a database, you need to know what you can spend. And before you sign a contract, you need to make sure you can afford to pay the bill, now and in the future. Over a five-year period, software could be as little as a one-fifth of your total cost. You might need new computers and printers, network upgrades, help in moving your data to the new system, extra end-user training, help developing new processes and policies, and perhaps even new staff to manage the system. This effect is magnified as the software price rises — more complex software requires more staff training, stronger policies, and better business processes. You also need to plan for the annual software maintenance fee, which is usually about 25 percent of the software's retail price. The bottom line: If you cannot afford to train your staff and pay the annual maintenance fee, do not buy the software.

3. Prioritizing Price Above Everything Else
Buy the product that meets your top needs, fits your resources, and offers the best price. Think in terms of Return on Investment. Software that allows you to have better control over your fundraising programs, manage your solicitations, track your results, and analyze your effectiveness is a good investment that will pay dividends for many years.

Accept a donation (whether of software or services) only if it fits your selection criteria. Feel free to accept input from board members, donors, volunteers, or the boss, but in the end, make an educated, strategic decision.

4. Randomly Looking at Demos
Yogi Berra is supposed to have said, "You've got to be very careful if you don't know where you're going, because you might not get there." And if you do not know what you want from your donor database, you might get to the wrong "there." Randomly looking at software demonstrations is not likely to produce a good result.

Your first step should be to convene a selection team that will help you make the decision. Make sure they understand their role — is it their decision, or are they advising management? Will the decisions be made based on majority rule or consensus?

The team should start by understanding the current system (what works? what doesn't? what codes and reports do you actually use?). Next, develop a list of needs. These can be general, like "ad hoc report writer," or specific, like the ability to track a 15-character appeal code or analyze membership upgrades, downgrades, and renewals. Don't forget to consider future needs, especially if major organizational changes are anticipated. Then the team should identify the mandatory items on the list. "Mandatory" means that if the system cannot provide that one single feature you will have to reject the database, no matter what else it can do. Everything that is not mandatory goes on the "wish list," which should be ranked roughly in priority order (for example, A, B, C). Consider what worked at your last job only if the needs, budgets, and staffing are similar.

Next, identify a pool of possible vendors. Links to several vendor listings are posted at www.rlweiner.com. In addition, you can ask for suggestions from your professional network, or on email forums for nonprofit professionals. Be sure to get references from comparable organizations (for example, type of nonprofit, number of staff, budget size, fundraising volume, number of locations, and so on). There is no point in finding out which database the Red Cross headquarters uses if your organization's annual budget is $250,000.

You might wish, or be required, to use a Request for Proposal (RFP). If you do, be sure that the questions you ask can be answered unambiguously, and will help you narrow the vendor pool. Think ahead to how you will use and rate the responses. Keep in mind that not all vendors will respond to an RFP, particularly a lengthy one.

When you look at software demos, make sure the vendors address your mandatory and top priority requirements. You can help ensure this by providing a list of your requirements, or a script that the vendors must follow. Make sure each vendor follows the same process: If you use a script for the demos, every vendor will need to follow the same script. If one vendor gets four hours for a demo, the rest should as well. Give each vendor the same information about your needs. If you answer a substantive question for one vendor, give the same information to the others. Follow up the information that vendors provide by checking references carefully and spending time testing a demo version of the software.

5. Falling in Love with Cool Features
Your donor database has to meet your needs and provide room for growth. But the vendor is also a critical factor. The right vendor will keep up with changing technologies, provide good training and support, and supply usable documentation. Remember, if the vendor disappears you will have to do this all over again. Reference checks will help you check the vendor's track record. If the company's stock is publicly traded, you can find detailed financial information. You can also get some financial information from [business information provider] Dun and Bradstreet. If the company seems risky, you might want to visit its office and see how it runs its operation.

6. Falling in Love with the Salesperson
You are not buying the sales person. In fact, in most cases you will never hear from the salesperson after you sign the contract, so don't worry about hurting her feelings. Try to look past who has the best personality or the nicest suit and judge the software on its own merits.

7. Buying More Than You Need
Don't buy a Ferrari if you only need (or can afford, or can maintain) a Honda Civic. It's great to be able to track every detail about every prospect and donor, but will your staff have time to use those features? Plan for the future, but make sure you can use it now. With some systems, you may be able to start small and buy additional modules as needed (although you will have to be prepared to pay for additional training and annual support along with the new modules). One often-overlooked option is improving what you have — it isn't reasonable to compare a five-year-old version of your current software to the most recent versions of other software.

8. Confusing Highly Functional Software with Highly Trained Staff
Complex software requires your staff to have more computer skills, not less. Under-trained staff, poor communication, dysfunctional business processes, and poor management will not be solved by new software. Usually, the problems will get worse.

It's also important to look at your staffing and procedures as part of the project. Beware of management and "people" problems masquerading as technology problems. For instance, if you are having problems getting accurate reports, are the problems being caused by the database software, sloppy data entry, lack of communication between fundraisers and techies, poor training, or bad programming logic in the reports? If it takes two weeks to produce a receipt, does the problem lie with the database or with your business practices?

9. Hoping That the Database Will Install Itself
Although it accounts for eight of the 10 topics in this article, buying software is usually the easiest part of the project. Next comes the hard part: the conversion project. Conversions usually have many components: mapping the fields, codes, and reports in the old database to the new one; cleaning up your current data (manually or through programs); figuring out what to do with data that does not fit easily into the new database; defining new codes and reports; testing the converted data; setting up business rules (how various tasks will be accomplished); defining system security (who can log in and what can they view, add, change, or delete); setting up system parameters (code types and values, user-defined fields); building interfaces to other systems; defining and documenting your procedures; creating a data-entry style guide; and writing training materials.

Someone is going to need to oversee that work. This project manager will need to understand your fundraising programs and learn how the software works. She probably has a full-time job that may be derailed by this project, and her manager will need to understand this before the project starts. The project manager is also likely to need help from your fundraisers and administrative staff, each of whom have their own jobs to do. Some organizations get through conversions by reassigning staff or hiring temporary staff to support the staff working on the project. Complex software must also be properly configured, which may require help from the vendor or a consultant.

If you have a hard deadline (like the end of the fiscal year), you need to make sure everyone knows this. You also need to consider the implications of missing it and have contingency plans in place.

Finally, you should try to build some flexibility into your budget in case unexpected costs arise. They say that time is money, but the reverse is also true. More money can pay for temporary staff, overtime, and more help from the vendor or consultants.

10. Leaving the Database to Fend for Itself
At long last, your new system is live, your data is clean, all processes and data-entry standards are documented, you have a training manual, and your staff are fully trained. (Well, you can dream.) The second law of thermodynamics says, more or less, that if you do not continue to put energy into maintaining the system it will degrade. How can you keep entropy at bay?

First, someone should "own" the database and be responsible for quality control. This role is sometimes called the "data manager" (as opposed to a technical "database administrator.") This person must make sure that your data-entry procedures are documented and followed, and run periodic audit reports to identify problems.

Someone will also need to make sure that staff are trained on new features and procedures, and that new staff are trained before they start entering data.

New systems often change the way work gets done. You will need to make sure that job duties and descriptions still match reality. You might also need to spend time thinking through how data and paperwork move through your organization.

Finally, you will need to budget for ongoing hardware and software upgrades, annual software maintenance fees, and ongoing training from the vendor — including attendance at annual Users Group conferences.