To be a successful data-informed nonprofit, it is important to establish good communication with the Database Administrator (DBA). Here’s a helpful guide to make sure you are speaking the same language!
English to DBA
1. Staff Member: I just entered a bunch of donors and gifts. I don’t know if I did it right, but at least they’re in there!
What the DBA hears: I have just ruined your database!
Bridging the Gap: There must be consistency in recording data in order to have a useful database. I can’t stress that enough. I would put it on a bumper sticker, if it wouldn’t bore the other drivers to sleep. You might have all the information you need on any given record, but that is not the measure of effectiveness of a database! If you use fields differently on different records, or if the format of the information is inconsistent, then you have no way to accurately search or report on the data. DBAs, you should have clearly-defined database policies and procedures for your organization to ensure that all data are always recorded in the same way. Also, make sure to utilize the user roles/security features of your database to define who can add/modify which data.
2. Staff Member: Thanks for getting me this list I asked for! Could you also add their total giving from last year? And maybe leave out any current or past board members?
What the DBA hears: Could you kindly start over? ‘Cuz I assumed you would just guess all of my secret criteria.
Bridging the Gap: This typically happens because seeing the actual results of what you asked for is such a clear way to identify what you really need. You have something in front of you that helps you see exactly what you’re missing, or unexpected results that help you identify criteria you overlooked. A good way to avoid this is to have something in front of you beforehand. Many organizations use data request forms that will take you through each decision you’ll have to make to get exactly what you’re looking for (e.g., which constituents should be included/excluded, which types of gifts should be considered, date ranges, etc.).
DBAs, if you haven’t already, you should create data request forms specific to your database. You can find some samples/templates here.
3. Staff Member: Hey, I’m going to be reporting to the board later today. Could you run a quick report on each of our appeals and campaigns? Just something simple, like how much we raised vs. expenses, year over year comparisons, that sort of thing. But I need it soon so I can look it over first!
What the DBA hears: I have no concept of how long it takes to do things!
Bridging the Gap: Plan for your data requirements in advance! Whether you’re segmenting a mailing list or reporting on your programs, try to stay ahead of your data needs and allow several days for your DBA to get you what you want. Yes, sometimes reports and queries can be quick and simple, but many tasks of a DBA are much more time-consuming than you’d expect. And keep in mind that you are probably not the only one making requests for data. If in doubt, discuss your needs with your DBA in advance to find out how long it might take.
4. Staff Member: I can’t connect to the network. Can you come take a look at my computer?
What the DBA hears: You are associated with the word “data,” therefore you are my IT person.
Bridging the Gap: Yes, some DBAs are in fact IT pros as well, and if your organization has one of those, congratulations! But a Database Administrator is not necessarily a techie, in the same way that a supermodel may not be a good seamstress. Sure, they probably know the industry to an extent, but their role is more of an expert user than a creator of the product. (I was going to go with pilots vs. aviation engineers, but when else will someone get the chance to compare DBAs to supermodels?) Of course, at many nonprofits, employees end up fulfilling several roles, and the database person often becomes the go-to IT “expert,” whether they like it or not. But just be aware that, though your DBA is probably willing to help with your tech needs, they may not “technically” know what they’re doing.
DBA to English
1. DBA: Sorry, that can’t be done. The back-end settings for the Bloviation Attribute don’t communicate that way with the Standard McGuffin Fields.
What your coworker hears: I’m too smart to even explain to you why your request is stupid. (Alternate translation: “I don’t know how. But if I use complicated words, maybe you won’t realize that.”)
Bridging the Gap: First, don’t jump to the conclusion that the request can’t be done. Just because you don’t think it will work the way they’re describing it, doesn’t mean there isn’t a creative work-around that could get them the same basic results they’re looking for.
Second, if it truly can’t be done, it’s important to explain in clear language what the problem is, either with a general summary, or even a step-by-step explanation when necessary. Then you can work together to find a solution that will get the job done.
2. DBA: “You know, with the way I’ve got it set up it’ll probably just be confusing if I try to show you how to do it. I’ll just do it for you!”
What your coworker hears: “I don’t want anyone to know how to use this database but me!”
Bridging the Gap: It can be tempting to do all database-related tasks yourself (out of wonderful altruistic selflessness of course, certainly not because you’re balking at the prospect of showing someone else some weird makeshift process you have set up). But you know what they say about teaching people to fish! In the long run, it’s better for everyone if the staff is well-trained at carrying out some of the common functions of the database that they’re going to need on a regular basis.
And beware of creating too many work-arounds in your database. Sure it’s fun, and often necessary, to come up with some creative outside-the-box solutions within your software, but too many hijacked fields and jury-rigged functions just make it impossible for anyone but you to find anything useful. Don’t worry about job security, no one else at your organization wants your job!
3. DBA: “Here’s the report you asked for. I don’t know how good it is, though, since some of the criteria you specified caused a lot of gifts to be included that probably shouldn’t be in there.”
What your coworker hears: “Did you want me to give you useful data? Sorry, I will only give you what you have technically asked for, not what you actually need.”
Bridging the Gap: Following the specifics of a request is not as important as fulfilling the purpose of the request. Make sure you’ve discussed it enough to understand the reason they need the data and how they’re going to use it. Then you can find the best way to get the information that will fulfill their objectives.
This is also true on a larger scale: your highest overarching goal is not to maintain a clean and accurate database. I know that sounds like DBA blasphemy, but it’s true. That goal should be a close second. Your highest priority that informs everything else should be to serve the mission of your organization. When everything you do to configure and run your database and fulfill data needs is geared towards successfully carrying out your mission and programs, you’ll have more than just clean and accurate data, you’ll have data that is actively and effectively serving its purpose.