Tuesday, May 27, 2014

What's the first thing you should do if you take over an existing database?

Golfland start 

It's not an uncommon occurrence that when a database manager leaves a charity, either no-one takes over their role immediately, or someone from outside the organisation comes in with no-one else able to help much with any background to the system they have taken over. If you find yourself in this situation as the new database manager, then what are first few things you should do?

Of course, some of this will depend on the size of the organisation you join, the size of the database team you are now managing (if any), how old  your new database is, if someone has been in post recently and so on. But the heart of my points below are true for most situations:
  • Data audit: One of the first things I would do is a comprehensive data audit. Unless you have an existing audit/report which someone trustworthy did recently, don't just take at face value what other people say about the database - find out yourself. Do record counts, table analysis, queries, reports; do this on contact records, gifts, communication/correspondence records, gift aid, ad-hoc fields. If you need to get the data out of the database to do this and do the analysis in Access/another package then fine - that's okay for a one-off exercise such as this. Once you've done the audit, then you can start to see what work is needed.
  • Talk: Talk to as many users, managers and senior managers as possible: Ask them about their roles, what they do, if they use the database, what they like about it, what they don't, what they really want. You've no drums to beat about why something does or doesn't work - you're brand new; ask them to tell you the truth, warts and all. This will give you so much knowledge with which to know how the database is really being used, to decide how the system could be used better.
  • Quick wins: If you can, do some quick wins thereafter - it's corny to say, but it helps! Especially if you can get it to help any sceptical users…
  • Create an internal development roadmap: Once you know what you are going to do, create a roadmap which everyone can see telling them your plans.
  • And of course there is lots more you can do…: Review processes, create a data dictionary, instigate a training and learning regime etc.
So, when the time is right for you to one day leave this role, your successor's job will be a doddle!

No comments: