Lun. au mer., 10h-16h, H de l'Est
1.855.281.5499 (sans frais)

Usability and Maintainability

Guidelines for choosing a nonprofit database

By: Rich Cowan

April 26, 2002

Editor's Note: Nonprofits often fall into simple traps when it comes to dealing with databases. Many of these traps can be avoided. Rich Cowan from Organizers' Collaborative argues that a nonprofit database is really a relationship tracking system, and he lays out seven tips to improve system design. He notes that keeping things simple may be the most important ingredient in database design and use.

The Adopting Technology Series is produced by Dot Org Media. Dot Org Media is a co-production of Marc Osten at Summit Collaborative and Michael Stein.

When I got back into the area of nonprofit database consulting four years ago, I naturally assumed that the use of databases in nonprofits would have advanced along with other high-tech innovations. Now, after learning about the donor and contact database systems used by over 100 small nonprofit and activist organizations, I'm not too sure.

Computers are certainly more capable -- in terms of graphics, speed, and storage capacity -- than they were ten years ago, and some groups are quite happy with their data management systems. But more often than not, the nonprofits I hear about have failed to reach the technological "promised land."

Usually these nonprofits have fallen into at least one of three traps:

  • The database system is complicated enough that only one person in the organization has been trained to use it effectively, creating a bottleneck and potentially a crisis if that person leaves.
  • After several years of using a database, a sizable portion of the information collected is obsolete or defunct, making it difficult for a group to locate contacts who are still active.
  • A organization "homebrewed" its database using Filemaker or Microsoft Access, but the developer (the executive director's brother-in-law is a phrase I often heard) never really committed the time to make it usable or to get all the bugs out.

These pitfalls can be avoided, but before I address how to do this, it is worth reflecting on how things have gotten so bad in the first place.

It seems to me that part of the problem is a definitional one. When people use the term "database," they are often referring to the computer programmer's definition of a database as one or more collections of "records," with each record made up of a fixed number of "fields." This definition is general enough to fit any kind of database that might be created using a system like Access, yet it fails to capture the practical reality of what a database means to a nonprofit.

The nonprofit's ultimate goal, after all, is not to gather as much data as possible on constituents and donors and volunteers in digital form. It is to allow staff and volunteers to share the work of improving the relationships established with those contacts and to continually record progress.

A nonprofit database is really a relationship tracking system. Thus the best nonprofit database systems make it painless to use and maintain the information about these relationships.

Of course, many ingredients go into good system design or evaluation. The following are a few suggestions that will help you avoid falling into the traps I mentioned above:

  1. Be sure that your relationships are well-understood before you hire a database consultant.
    A national educational organization was using aboutfour different database fields to determine who got the newsletter, and only the founder completely understood how to use them. When they wanted to convert their database to a new system, these "rules" were finally written down, but they were ambiguous. In this case, the organization had not completely determined its business logic, which is a prerequisite to good database design.
  2. Make sure the database system includes shortcuts for the tasks you repeat most often.
    A national economic justice group is currently supported by more than 5,000 grassroots donors. They moved their system to a free database package that required navigating through several screens and fields to enter a single donation. After navigating through these screens more than 100 times in a week, they realized that they needed a different system, and they are now in the process of transition.
  3. See if the relationship tracking features can be customized as the organization changes.
    A state-based citizen participation group in Massachusetts started using a custom database system in 1985 and had defined about a dozen "participation codes" indicating the involvement of the most active of its 4,000 members. In 1999 they recognized that most of these participation codes were obsolete, but the system had no mechanism to easily remove or hide that obsolete information. Needless to say, they are now moving to a more modern system.
  4. Make sure that there is a method for avoiding duplicates.
    A congressional campaign had a strong base in the Armenian community, and entered about 400 names into an Access database. Though there were initially only about four pages of Armenian names, some of these pages were typed in three times. Within a few weeks, many of these potential supporters began receiving six phone calls for the same event and the problem was not immediately corrected. Needless to say, the candidate's support in the Armenian community was never the same. At a minimum, a database should have a mechanism to allow the screening of duplicates during data entry and during the "import" operation.
  5. Consider long-term maintenance issues.
    The educational organization I mentioned earlier often included capitalized words like "DECEASED" and "DEFUNCT" and "XXX" within the address fields so that they could scan their printed labels and remove the bad addresses before each mailing. Though their instinct not to completely delete those records was a good one, they would have been better off if their database system had a standard mechanism to segregate inactive names from active ones.
  6. Add prospects judiciously.
    It's easy nowadays to collect thousands of names from other groups and add them to your main database. But unless your system keeps these "prospects" segregated from your "active" list, this is generally a bad idea. You might be better off keeping "prospecting" lists in a separate list. A relationship tracking system cannot work well if you have no relationship with most of the people it contains. Prospects can be added to this system if they show actual interest in your group.
  7. Add fields judiciously
    A national environmental group I worked with created a Filemaker database in 1992 with around 80 fields for every contact. This made sense for the first couple hundred contacts entered. But within six months, 20 of these fields were no longer used, and within a year, half were no longer used. The group could have saved itself from a major redesign if it started with only the fields that were absolutely necessary.

Finally, it is important to consider the scale and budget of your organization. If your group does not have in-house technology support, don't spend $3,000 on a complex system, as an immigrant organization in Boston did last year. This organization had to mothball their new database after only a couple of months because staff members could not use it. Keeping it simple (KISS, as they say) can go a long way toward making the transition to a new database system a smooth one.

About the Author:

Rich Cowan is on the Board of Directors of Organizers' Collaborative, which provides technology and training to advance and sustain social change.