Good software, bad choices: 10 common mistakes in selecting donor databases.

Picture two nonprofits. The first has a donor database that is full of bad information. Donors are getting the wrong receipts or no receipts at all. The organization cannot use the database to plan their fundraising strategies or track their effectiveness. The few reports they 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. The data is clean. Donors get timely, accurate mailings. The organization has a good handle on its fundraising activities, and staff members 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 or used it incorrectly. They made a series of bad decisions and have been struggling with them ever since.

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

Programmers created all donor databases in the early days of computing. 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 in designing a database, programmers usually drove the project.

Although the market for donor databases has changed significantly during 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, from fundraisers in all areas of development (direct mail, grants, major gifts, corporate relations, and planned giving, etc.), and other staff who might 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.

During a five-year period, the actual software could be as little as 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 (ROD. 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.

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. Next, it should 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 (e.g., A, B, C).

Next, identify a pool of possible vendors. 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 (e.g., type of nonprofit, number of staff, budget size, fundraising volume, number of locations, etc.).There is no point in finding out which database a large national headquarters uses if your organization's annual budget is $250,000.

You might wish, or be required, to use a Request for Proposals (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 seems risky, you might want to visit their office and see how they run their operation.

6. Falling In Love With The Salesperson

You are not buying the salesperson. In fact, in most cases you will never hear from the salesperson after you sign the contract, so don't worry about hurting feelings.

7. Buying More Than You Heed

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 might 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 now. It isn't reasonable, however, 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.

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.