Once you’ve investigated the first three questions about friction in your database—perceptions, people, and processes—it’s finally time to consider the platform itself. Here is part four of “Everybody’s database sucks.”
If you’ve been following along with this series, you’ve already considered three reasons your database sucks: perceptions and misperceptions; processes (and the lack thereof); and the people involved with your database (or missing).
You are in good company when you find your database aggravating and even odious. You’re with most people. But I hope that you’ll avoid the trap of rushing to blame the platform. Ask the salient questions, consider all the ways your database may be problematic—and how, then, you can fix it—and only after that consider the platform.
But even then—arriving at last at the platform as the source of your woes—even then we should patiently ask questions as to why the platform is a pain point and what precisely would solve this pain point.
PLATFORM PROBLEMS
The platform you use as your development database most definitely can cause problems. Not all databases are created equal. Not all organizational needs are the same. Having the correct tool for the job is vital. Here are some common issues relating to platforms that organizations should consider.
Who does the development database serve?
This sounds like an obvious question but if you’re smart you’ll lay down the law early and often. The development database serves the Development/Fundraising/Advancement department. Do not let Marketing, Communications, Programs or (especially) Accountants get their fingers in your development database.
I’m sure your organization has all of these folks and I’m sure they’re all good people. But their end goals are not the same as yours. Even with the best of intentions, they will twist and deform your database to serve their ends, and too often the development department is left holding the scraps.
Does your system fit your processes?
Remember: don’t let your system determine your processes. Plot out what it is you do and then use a platform that will do what you want. This applies to:
- Donor tracking and management
- Campaign Tracking
- Donor Segmentation
- Moves Management and Activity Tracking
- Reporting and List Exporting (don’t skimp on this!)
- Grant management
- And more!
If the system simply doesn’t let you do what you need to be effective fundraisers, don’t let it hold you back. Plan to migrate. But only if you want to be more effective fundraisers. And if you plan to migrate to something that you know will do what you want it to.
Is your platform scalable given your growth and goals?
Have you taken an honest look at your growth trajectory recently? If your database barely scrapes by, will it really serve you well as you grow? Should you build a bigger, better (and scalable) system before or after it all starts to fall apart?
Are things going to get less complex or easier to migrate if you wait months or years?
Is your platform alright for now?
Lest the previous point inspire you too much, sometimes a system that adds complexity and capacity is not the best solution. A super-hot startup with loads of outside capital and huge reach could easily outgrow a legacy system in a year.
On the other hand, if you’re on the smaller side with a few hundred donors and planning to grow by a respectable 20% that’s great! Don’t get sucked into the latest and greatest tool if what you have is working for you. Don’t chase the new, shiny object. But have some goals in mind of where you want to be and then have a game plan for when you will change or update your systems.
Don’t pick a system purely on cost.
Don’t pick a database because of a sale or a deal or a super special deal. Pick a database because it’s the right solution for you. Even solutions that offer free versions to Nonprofits (e.g. Salesforce) may not be the right solution!
You will always pay. I can’t emphasize this enough: YOU WILL ALWAYS PAY! It’s just a matter of who and when. You might pay the vendor, you might pay an outside consultant (like yours truly). Maybe you do all this up front, maybe you do it after months of frustration, but you can’t escape it. And even if you think you’re not paying because there’s no monthly free, you must consider the hours debited from your life as you battle, alone, to build a database brick by brick. Don’t make the mistake of being pennywise and pound foolish.
Beware the salesman.
I will confess I’ve never been in sales so there are far better experts than me, but I’ve seen enough to give a few reminders about salesfolk:
- They are not your friends. And they don’t generally have your best interests in mind. They rarely even understand what it is you actually do.
- Don’t let them pressure you on timelines. If you can make a purchase work that also corresponds to some promotional deal, great! But do not let them control the timeline.
- They are generally not proficient in the technical aspects of their products and will say and agree to just about anything necessary in order to make the sale. If you have technical questions, insist you talk with people who know what they are talking about—that will save everyone time and frustration during the migration process. It will also save you from getting too far down the line that you go along with an imperfect product and find yourself in the same position two years later.
- You have to understand exactly what it is you’re buying, exactly what it does, and how you will use it. This doesn’t mean you need some engineer who understands every bit of technical minutiae. Think of it like a car sale: You know what a car is generally supposed to do and what it’s supposed to be. And if you don’t trust yourself, you bring in a friend or mechanic. But at the end of the day, it’s important you know you’re getting a car and not a trebuchet. The same is true in any software purchase. Don’t just buy it because the smiling salesman says it’s going to fix all your problems
WHAT'S THE TAKEAWAY?
Why discuss platforms last? Because it’s usually the first place people go when they have problems with their database. But often there are deeper problems that will then carry over to the new database if you don’t address them first. After that, you might need to evaluate your platform and decide if it’s the best for you given its capabilities and limitations.
But moving to a new platform is a hard and risky process and so I generally make sure that my perceptions, process, and people are all alignment before discussing what can become a much larger and time-consuming project.
Think about your database. Are the problems you face truly with the platform? If so, how long before you need to look at a new solution? Could tweaks and adjustments in your current database solve issues, rather than a complete overhaul/migration? Who can you turn to for insight on your particular situation?
CLOSING THOUGHTS
I hope this series has proven useful in helping you meaningfully reflect on the problems your database creates for you, and how you might address them. Remember: your problems are not unique. We are all facing unending battles wrangling in the ever vexing “database”—but informed and thoughtful consideration can reduce some of the stress, friction, dissatisfaction, surrounding your database.
I often refer to the database as the house where your data lives. It’s also much more: it’s the connection between the past and the present. It is your organization’s shared memory of happy news and sad. It contains the lives you’ve impacted, the donors with which you’ve partnered, and the differences you’ve made. Within it lies lessons, stories, wisdom, failures, and victories.
Patiently and thoughtfully, you can use your database to do more and be better. You need only open the door and look around. So don’t lose heart: Everyone’s home has some dirt. Everyone’s family has drama. Everyone’s database sucks.
This article is part four of a four-part series. You can read part one here, part two here, and part three here.
