You probably feel it, too: “my database sucks.” Here are the four reasons databases suck—and what to do about it. The first in a four-part series.
Some years ago, I came to the realization that everyone’s database sucks.
It’s not that our databases are useless or without purpose. That’s certainly not true. But what I so often find is that the expectations we have for our database don’t match reality. The database is confusing. The data is hard to get out, hard to put in. The answers we get out are often wrong or at least unreliable.
So why does this happen? I’ve found four main reasons why everyone’s database sucks:
- Perception
- People
- Process
- Platform
THE PLATFORM PROBLEM
Often, when people have issues with their database they rush to the platform. Something must be wrong with the tool we’re using, they think. So they get another platform, rush through a migration, leave a wreckage of duplicates and mangled data in their wake, and then repeat this process three years later. Rinse and repeat.
Before rushing to conclusions like this—slow down. There could be any number of reasons why your database isn’t performing the way you would hope. Sure, it could be the platform you use, but it’s best to consider each of these reasons so that you can accurately identify—and then address—the problem.
Do you know the biggest response I get from clients when I tell them “Everyone’s database sucks”?
Relief.
Most nonprofit professionals feel it. Well: You’re not alone. You’re not facing unique or insurmountable problems. We’re all facing the same battles and have many of the same issues.
I hope this series will give you the confidence and resources to identify problems and craft solutions.
PERCEPTION AND PUZZLEMENT
The first reason your database sucks is that people are confused about what it is and what it does.
Here are some common mindsets that get us into trouble:
The database feels like a black box. There should not be an arcane and mysterious aura surrounding your database or the data within it. A database serves two primary functions: you put data into it; you pull data out of it. Don’t let it be scary. That means someone—someone—at your organization (or a contractor) needs to be familiar with the database and needs to take the time to train others.
The database is never right; all our data is a mess. This might be true, but it doesn’t have to be. Your data should be trusted. Your data should be clean. If you believe that a database is an irreparable mess, why would you ever bother trying to change or fix it? Why would you spend valuable time putting good data in?
The database is never wrong. It must be treated as Gospel truth. This is also never true. Your database is only as reliable as the data that is put in. It’s like they say: Garbage in, garbage out. Even if your forms are strict and quality control is emphasized, there’s still an aspect of human error that simply cannot be completely avoided. And remember: error creeps in when data goes in and when data comes out. That's why setting up checks and balances, audits, and periodic reviews are important to make sure errors are caught early and often before they propagate through your system and beyond.
We don’t need a database administrator. Call it what you will, your database needs an owner. Someone who takes responsibility for shepherding the system. This role is a hat that someone has to wear or your database will go to seed like an abandoned field full of dandelions. This person can spot issues and implement changes before issues metastasize. It’s a lot easier to plug a few holes on a boat than salvage it from the bottom of the ocean floor. Or, why mix metaphors: it's easier (and more efficient) to weed a field consistently and frequently, rather than rarely and extensively.
Automations will fix our problems. Automations rarely fix problems. Automations simply automate a previously manual process. Automations address issues related to capacity. Don’t run to automations to escape the hard work of making sure you have the right people, processes, and platform. If you can't do something manually, then an automation won't fix a problem—and it might introduce a new one.
By "this date" our database will be “done.” I hear this one a lot. What most people mean is that they want their database live, functional, and in good working order to service their needs. But the perception here is important: “done” communicates to your team that there’s a point at which we "set it and forget it." The thing is built and now we can move on. Not quite. Just like that field of dandelions up above, your database is never "done." It can be live and functional by a set date, but it still needs maintenance ... "weeding," if you will.
Everything needs to be integrated. Why? That’s not a rhetorical question. You actually need to be able to answer this question. Leaders often demand integrations and employees dutifully nod their heads. But what problem are you actually trying to solve by doing this? Some integrations are straightforward and very useful. Others are time intensive and of dubious utility. Each database you have—whether development, marketing, accounting, or programs—serves a specific purpose. Some of these may need to be integrated, may need to talk to each other. But you need to carefully consider the “what” and “why” of each integration before charging ahead.
WHAT'S THE TAKEAWAY?
The first step to addressing a database that sucks is your perceptions and misperceptions.
Consider whether you or your staff have any of these misperceptions. Then talk about why that is the case. Get to the root of issues so they can be addressed appropriately. Correct misunderstandings and then make wise decisions with your database.
Then try this: Start with the end in mind. Clearly articulate, “This is the content and format we want in our database. These are the kind of reports and KPIs we want out of our database.” If that changes your expectation of what your database is and what it can be, you’re already on your way to making those changes a reality.
This article is part one of a four-part series. You can read part two here.
