Since you clicked on the link to this blog post, chances are you are having trouble with your database, or maybe you know someone who does. Well you aren't alone. In this series we're looking at three things that can make your database suck be less than ideal. Last time we looked at what happens to your database when you have no standards. Today we're going to look at...
Part Two: Secret Stashes [More]
On Friday I co-presented a session called Stop Keeping Secrets from Your Database: Eliminating Rogue Databases, at the MCN Technology & Communication Conference. Many thanks to my co-presenter Joel Barker for technical heavy lifting, pulling the visuals together, and altogether being a great person to work with.
My favorite part of the presentation was the little video we slipped in there, based on a popular meme you've been seeing all over Youtube, Stuff Rogue Database Users Say.
Here are links to the Prezi Stop Keeping Secrets from your Database, and the handout with resources and further reading.
I appreciated the generosity of those in the audience with a strong technical background who shared tips and insights, as well as those who confessed their frustrations and challenges.
What stood out to me in researching and preparing, and then facilitating discussion, was how complex the issue of rogue databases can be. There is no magic pixie dust that makes them go away. For techies, the first instinct might be to alter or replace your database or write clever routines and scripts. But I think we all recognized that you can't rely solely on a technical solution, to what is often a human problem. Take the time to include stakeholders, address their data needs as well as their psychological needs, and build a culture of data. As Joel summarized it, "Be open to new ideas and collaborate with colleagues to find solutions to your organization's data needs."
Previous posts in series: 6 Reasons Why Rogue Databases Happen | Is Integrating Databases Worth the Effort? | Bringing Rogue Databases into the Fold: Case Study
We've talked about why Rogue Databases exist and established that it's a problem. Are you ready to do something about it? Here are five tips you can use. (Don't panic; most of these tips do not require money or advanced technical skill.) [More]
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." [More]
What's the big deal about rogue databases? This is the second post in a short series I'm writing on Rogue Databases: those spreadsheets and contact files that exist outside of your "official" database. Last time, we listed some of the reasons rogue databases keep cropping up. In this post, we'll cover a few ways they can hurt you, and benefits of controlling them.
How rogue databases hurt you
In general, rogue databases can lead to wasted resources and missed opportunities. Here are a few ways this can take shape: [More]