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

 

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!

The Benefit of Documentation When Implementing New Databases

 

So: If you're reading this blog post and wondering why I am even bothering to write it - because of course documentation is important - then great! You can stop reading now! Go and have a laugh at today's Dilbert instead. But if you do doubt the benefit of documentation in database implementations (or if you like the sound of documentation lite…) then read on… Because this is why I think documentation is important:

• Structure for project managers: It gives the people running the project structure - it helps them see what's what, where we are, what we are doing, who's doing it, what needs to be done and so on. I know these are easy words to write and perhaps not tight enough (especially for a blog about documentation!) but this is the heart of the benefits which documentation brings. As a project manager it gives me what I need.
• Structure and assurance for project boards: Following on from the above point, it gives your project board the same assurance and support.
• Accountability: This is important. It means that we have a written record as to what was discussed, decided, agreed (or not), for who, by when and so on. It's especially useful for when disagreements arise between a supplier and client, as we can then have at least a starting point to discuss.
• Blueprints: For projects which do require some up-front consideration of how the database is going to be configured, especially where a third-party supplier is doing that work, blueprints are pretty much essential. This is what was decided by client and supplier, this is what the supplier will deliver, and this will help formalise the project and avoid (a set of) arguments later about this.
• Data dictionaries: I wrote a blog recently about the benefit of data dictionaries - I still believe all that.
• If someone leaves… I've been brought into projects where an organisation is half way through a database implementation and I have needed to catch-up quickly with where they are. The better the documentation - i.e. the more poignant it is, not necessarily the amount of it - the better it is for someone new to be able to get up to speed.
• Agile methodology: I know some Agile evangelists believe that documentation is not so helpful because things can change so quickly in the next sprint anyway. I guess this is something that every Agile implementation needs to consider: is there some space and reason to have relevant documentation? Or do we agree it's not necessary. It might worry me sometimes…
• The more attentive of you will have realised that much of what I am promoting is to do with "clients and suppliers". Yes, that's true. I do think this is where documentation can help. It keeps everyone on track, maintains a level, fair playing field for both parties and I think instils good practise in implementations.

Then of course there are project plans, risk registers, communication strategies, data mapping tables, file formats for data integration and so on. I realise that even fans of documentation lite might see these types of documentation as more useful, but that doesn't always seem to be the case in my experience. Personally, I think we need them.

And just to finish with a couple of caveats: Documentation does not have to mean wreathes of paper - a well structured, online system of "documentation" can be just as useful for many of these issues. As long as it is structured, searchable, auditable, accessible then great, I'm all for that. And I am not saying that you need to follow PRINCE2 to the letter and create Product Descriptions to the nth degree - i.e. I'm not saying you should have documentation for documentation's sake. I realise there are times when keeping documentation to a minimum - or rather, to the amount appropriate for your organisation and your implementation - is right. But I still think documentation is needed.

Why you need to listen to Donald Rumsfeld when implementing CRM systems...

 

Some years ago, Donald Rumsfeld made his now infamous speech about known knowns and known unknowns. He of course got pilloried for it and was even given the Foot in Mouth Award for Bad English. And whilst I understand why he got such criticism, I would like to add one caveat: if he had been talking about CRM software implementations then he would have been lauded a genius!

Why?
Why?! Well, because I think he (unintentionally!) got the absolute essence of the problems you have when implementing databases:

• First, the Known Knowns. Absolutely. We definitely have this - the processes and data we do know we have and we know we have to address in the new system. Tick.
• Then, the Known Unknowns. Right again. These are the areas of our business which we know exist: the spreadsheets which we have heard something about, the small Access database which the trading team use - the data which has been in our database for 15 years and which, although we know it is there, we know nothing else about it! These are the things we know we have to tackle with a different approach when considering the new database.
• And finally, the Unknown Unknowns. Ah yes - these are the horrible but inevitable things that occur in almost all database implementations. The things we didn't even know existed, the problems which no-one had even imagined we should consider, let alone resolve. They will happen - of course they will. And it's no-one's fault, it's just that some things may simply have never reared their head before, or something no-one other than the database manager who left 3 years ago knew about - or the issues which the fundraisers know are a problem but they have never discussed them before. They're lurking there somewhere…

My real point...
I genuinely think these are useful things to consider when implementing a new CRM or fundraising database. If you go into the project with this in mind then at least you can plan for even the Known Unknowns. And you might even be able to come up with some process for how you are going to tackle the Unknown Unknowns when they pop up; e.g. in terms of business analysis, documentation, impact assessment, forewarning users that if this happens then this is how you will approach it.

I'm not saying you should stand up at the kick-off meeting and quote Mr Rumsfeld word for word - but do let him sit quietly on your shoulder so you can call on him when needed.

Is Microsoft Dynamics Emerging as a Leader for Higher Education CRM?

UCISA, the Universities and Colleges Information Systems Association, which represents higher education in the provision and development of academic, management and administrative information systems, has recently published the results of a software survey they did amongst their members. And this shows that Microsoft CRM Dynamics is the most popular choice in their "CRM" category. The survey is carried out annually by UCISA and provides a simple snapshot of the core corporate information systems in use by UCISA members and although the previous year's results showed that Dynamics was already fairly well used, the usage has increased again this year.

Now, it should be said that the list of products in the survey's CRM category is fairly wide-ranging. Dynamics on the one side, which could cover a number of areas; The Raiser's Edge and thankQ as other examples, which manage fundraising and alumni relations; Hobsons, which is more about admissions communications; and even Agresso, which is an ERP system which could be used for finance through to HR and Payroll. Plus a number of other systems of various ilks.

As such, it is difficult to really compare like-for-like or to say that one system is actually stronger than another for a specific application. And it could even come down to what a survey respondent defines as "CRM". For example, the survey also shows The Raiser's Edge with only 12 users and thankQ with 2, when Blackbaud and The Access Group certainly have more than that number of clients in Higher Education establishments. There is also no mention of any Salesforce users at all (although my understanding is they do have Higher Ed UK clients which one would think would be classed as CRM).

But what it does show is that Dynamics is certainly on the uptake. If you look at the UCISA results over the last 4 years then it shows a steady but distinct increase. It is a flexible system (like other CRM solutions) and as such could be being used for anything from fundraising and alumni relations through to general contact management, specific student record management/communications and so on.

This probably reflects what is happening the charity sector too. Several years ago, Dynamics was starting to find its feet in fundraising and other charity CRM applications, but now in 2014 it is starting to make waves.

Interesting times lay ahead…