Years ago, we wrote a post titled “It’s Just a Database,” emphasizing that a database is just a tool, and it’s only as good as the data you put in it. Now, we are revisiting that theme in response to a common request we receive.
Nonprofits often reach out to us seeking help to transition to a new database. They are at their wits end. Their complaints include some combination of the following:
- We can’t get our data out.
- It doesn’t capture what we need it to.
- It doesn’t support our workflows the way we want it to.
- It’s not integrated with or doesn’t “talk to” our other systems.
- We have multiple systems, and we want to consolidate into one.
- Our users tell us it’s too complicated or otherwise not user-friendly.
Organizations often suffer through these challenges for months or years, letting frustration, disillusionment, and resentment build until leadership is suddenly ready to throw in the towel and start over with an all new system.
There seems to be this idea that there is a system out there that will solve all their problems and meet all their needs. There isn’t.
They often think that starting over with a new system is the only option. It’s not.
I am going to go out on a limb and say that in most cases, the problem actually isn’t the database itself.
It’s not a software problem. It’s a design, process, program, or people problem.
Databases are just containers – containers that you design or hire someone to design for you. They are only as effective as you design them to be. And they are only as useful as the data they contain.
Top 7 Reasons Your Database Is Not Working For You
1. It’s collecting the wrong data.
That’s not its fault. You decided what to collect when you designed the database. Whether you’re collecting too much or not enough or collecting data in unusable formats (i.e., lots of open text fields), that’s a planning and design issue.
2. It doesn’t contain the data it should.
If your staff aren’t interacting with the database regularly and aren’t entering data as expected, that’s also not the database’s fault. That’s a process problem and an oversight issue. There’s a common, vicious cycle at play here. If the database is collecting less-than-meaningful data, then managers won’t use it. If managers don’t use it, staff are less inclined to collect and enter it. As staff stop entering data completely, accurately, and regularly, your dataset becomes less useful. And they cycle continues.
3. No one is overseeing data quality.
If the data staff enter disappears into a black box, never to be seen or heard from again, they lose motivation to collect and enter it (see the cycle described above). With regular oversight of data quality – is it complete? Is it accurate? Is it on time? – staff come to realize that the data are important, that processes matter, and that quality data can be used for important learning and decision-making, and poor quality data is a waste of everyone’s time.
4. It was designed only with thoughts of getting data in, not getting data out.
Like most of the work we do, database design has to start with the end in mind. You have to know what questions you want to answer with your data, so you know what kind of reports you want to generate. This, then, tells you how your data need to be organized and related to one another. That, then, tells you how the data need to be collected. Designing databases only with data collection workflows in mind often overlooks the relationships and structures you need in order to get the data out. Not being able to get the data out is usually a result of how you designed the screens to put the data in.
5. Users aren’t trained.
Successfully onboarding a new user involves more than issuing login credentials and demonstrating data entry processes. Users need to also understand which reports the data feeds and how the data is used. They also need to understand the overall database structure, so they understand why a process takes 12 clicks. If they understand the rationale behind the system’s design, they are more likely to invest in using it as intended.
6. Users aren’t engaged in process improvement.
This one is often at the root of the problem. When organizations reach out to us for support with selecting and designing a new database, usually, their current one has been neglected for years. When users encounter bugs, inefficiencies, or inadequacies, they just throw up their hands, create a workaround, or give up on the data. Instead, your users need to have an invitation and a forum to bring forward problems and participate in problem solving. Don’t let frustrations and bugs accumulate to the point that everyone is ready to throw the baby out with the bathwater. Our friend Tim Lockie and his team at The Human Stack have a great approach to this!
7. Administrators don’t have the capacity, competency, or confidence to manage the system.
Databases are not “set it and forget it” tools! They require active, ongoing monitoring and maintenance. Organizations need to adequately train and support database administrators and super-users as back-ups. Document your database design and procedures, so nothing is lost during transition to a new administrator.
The Bottom Line
Before you blame the database and gear up to make a major investment in purchasing, designing, and migrating to a new one, carefully reflect on the pain points in your current system and the root causes of those problems. You might discover that you can save time and money by re-investing in the people that are using and the processes that are supporting your current system.
In our next post, we’ll share our top tips for combatting these common problems. Stay tuned.