We’ve talked a lot about why Rogue Databases exist and established that it’s a problem. Are you ready to do something about it?

Five tips to eliminate rogue databases:

(Don’t panic; many of these tips do not require money or advanced technical skill.)

1. Switch to all-in-one tool (e.g. Constituent Relationship Management software)

Given that an all-in-one CRM for nonprofits pays my salary, you shouldn’t be surprised that this my first tip. Many nonprofits, especially those with small budgets and lacking IT staff, find this is the best solution. You’ll have a single database, with a home for all of your rogue data, and integrated communication and reporting tools.

Make sure it is flexible enough to accommodate the needs of different users, and make sure high quality customer support and training are available.

But be honest with yourself: new software will not solve all your problems, especially if your organizational culture does not support collaboration and good data management practices.

2. Utilize training and manuals

This addresses one of the biggest reasons rogue databases exist in the first place: because people don’t know how to use the “official” database. Attend the training. Watch the tutorial. Read the manual.

3. Import/export

This is a reasonable alternative to an all-in-one system. Transfer files from one place to another as needed, ideally keeping a comprehensive list in your “database of record.”

Any database worth its salt will have a unique ID number for each record. When consolidating data sets, keep the old IDs attached until you are certain everything has been transferred. Use a source code indicating which file this data came from. Similarly, when exporting data, include the ID from your database so you can easily import back the results.

Duplicates are an inevitable by-product of importing and exporting. Some things to think about: Which list has the most up-to-date information? How should I determine duplicates? Two good starting points are “email address & first name” OR “first name/last name & zip code”.

If data is scattered to the winds, now is a great time to corral it again. If you had 50 different fundraising campaigns dating back 20 years that no one can make sense of any more, consider putting all that data under the same legacy campaign in the new system.

4. API

An API allows software systems to talk to each other. People with a solid technical background may be able to automate many routine manual tasks by utilizing their system’s API or extend/customize software functionality that is specific to their organization.

An example: People and contributions coming from one organization’s personal fundraising site are automatically entered in their main database, via API-based integration between thedatabank nonprofit CRM and SWEET personal fundraising solution.

Another example: Maybe you go through your new signups for the week and mark them into a certain category depending on what county they are from. Utilizing an API you could automate that manual process and do all the updates at the click of a button.

One more example: You’re preparing a renewal mailing, and you want to personalize each ask amount according to a formula. You might create a custom script that pulls data out of your database, runs the data against the formula, and spits out a .CSV file on the people, their address, and their personalized ask amount. Smarty pants. Give yourself a gold star if you can do this.

5. Back to basics

Maybe you have great software, and procedures, but rogue databases persist. Is it possible your colleagues just don’t get it? Have some strategic conversations about why you collect data and how it supports your goals. Identify the real reasons people are keeping secret files, and get everyone on board.

Thanks to my colleague Adam Oien for contributing his invaluable techie perspective to this post.

But Wait – You Could Learn about Rogue Databases Live and In Person!

I’m presenting this week – Friday 3/16 – at the Minnesota Council of Nonprofits Technology and Communication Conference. Minnesota readers, if you’re attending, please come to my session Stop Keeping Secrets from your Database: Eliminating Rogue Databases at 3:15. I’m co-presenting with Joel Barker. If you’re not able to attend, not to fear – I’ll post the presentation materials here, early next week.

Previous posts in series: Six Reasons Why Rogue Databases Happen | Is Integrating Databases Worth the Effort? | Bringing Rogue Databases into the Fold: Case Study

Up next: Presentation Materials from MCNtech Session

%d