“Success with a shared database platform requires top-down and bottom-up buy in to the selection process, and the design and use.” ~Dale Blyth, University of Minnesota, Extension Center for Youth Development
The Center for Youth Development (CYD), an organization housed within the University of Minnesota and consisting of many smaller units, had a lot of contacts and relationship data to manage. They tracked program participants, event registrations across many types of events, professional colleagues, and committees, to name a few. The problem was, every unit – and in some cases each staff member within a unit – had their own way to track the data. While they may have stopped short of labeling these files rogue databases, the Center’s fragmented data management system was not as systematic as they wanted it to be. According to Dale Blyth, who was Associate Dean at the time, “As the programs and technology evolved, everyone found a solution. But they were all different and idiosynchratic, based on the staff member’s expertise and history. We wanted to do it in a more unified way.”
Bringing Rogue Databases Together
Melissa Pierce of the Youth Work Institute, a unit of CYD, led the way by intiating a search for an alternative to their Microsoft Access database. Blyth realized that improving data systems throughout CYD could help them be more efficient, give everyone access to the data, and use their lists more strategically and systematically. However, some staff members were hesitant to change. Would a new system be hard to learn? Would it be flexible enough? Would they lose control of their data? These objections were overcome by focusing on the benefits of a new, shared system, and overall the idea was received with excitement.
The situation was further complicated by CYD’s relationship with the university, which has strict guidelines on software and sometimes mandates use of particular products.
CYD chose the Databank as their new Constitutent Relationship Management (CRM) software platform. They needed a flexible product that was relatively standardized and well supported, and already had all the basic features they needed. They chose not to pursue a custom solution, because as Blyth explained, “You don’t want to be left out in the wilderness if the person who built [the software] is no longer available or doesn’t keep up with rapidly changing technology.”
They wanted to consolidate as much as possible. The Databank was able to merge all of the Excel spreadsheets, Access databases, and other files containing program and communication data. They chose to continue using a specialty product for donor management, even though the Databank also offered that functionality; because they were heavily invested in it and the benefits of conversion did not seem to outweigh the effort involved. They continued using a separate, enterprise volunteer management database for their 4H program for similar reasons.
Benefits of Consolidation
Now that CYD has a shared database for all units, it helps them manage the whole relationship with constituents. A few tangible benefits include:
- They’ve substantially reduced duplicate mailings.
- They coordinate online and offline communication so people aren’t hearing from them too frequently or too infrequently.
- Everyone can see what communication has gone out.
- One person can send organization-wide communication, instead of always relying on each unit to send it on to their own list(s).
- Leadership and support staff are learning a common language for talking about lists and data.
- Responsibilities for data management and communication have been clarified, though staff member Jan Logelin noted there is still work to be done here.
- Gatekeepers provide structure but don’t stand in the way; if someone is on vacation, a coworker can still access the database.
- New features like online event registration and email blast expand CYD’s outreach capacity.
Automation frees staff members from busy work.
Advice to Other Organizations
One of the keys to success with a shared database, according to Logelin, is to “plan ahead and think about what you want to share and what you don’t.” She continued, “It’s not essential to have a single person in control, as long as procedures and policies are in place.” Putting those policies and procedures in place, and getting everyone to follow them, is no small task.
Blyth emphasized the importance of involving people from all parts of the organization. “It requires a combination of a top level decision that you are going to invest in this – time, energy, thoughtfulness, leadership commitment – and involving people from the administrative side to make sure it is practical and meets their needs,” he said. Operating inside a common software system means the software must be useful to, and usable by, everyone.
One should also think about human resource implications: the amount of time required to choose and implement new technology, the way it will affect people’s tasks and routines, and the training needed to get the most out of the software investment. Blyth advised organizations to assess the technical expertise on their staff, and get external help and training if needed, to strengthen their capacity. Change the way your staff think and operate in regard to technology, in ways that simplify what they do and increase effectiveness, he said.
All of this underscores the importance of choosing a technology vendor that takes the time to understand your organization’s needs, designs an appropriate solution, and follows up with responsive service and training.
Consolidating databases is a big project, and one that can have a big impact. You’ll learn more tips for consolidating, in the next post in this series.
P.S. Heartfelt thanks to Dale and Jan for sharing this story!
Previous posts in series: Six Reasons Why Rogue Databases Happen | Is Integrating Databases Worth the Effort?
Up Next: Five Tips for Consolidating Rogue Databases