The 3 top reasons why you should still consider traditional fundraising software

 

So much is written now - by myself included! - about the (now not so) new CRM systems (I.e. MS CRM Dynamics, Salesforce et al) that you could be forgiven for forgetting that there are still other options. But the good ol' traditional fundraising database package is of course still going strong (e.g. Raiser's Edge, thankQ, CareNG, Advantage Fundraiser etc), and it is still selling well (out-selling CRM?) and there are clear benefits for at least considering it if you are looking at a new fundraising database solution.

These are my top three reasons why you should still consider the fundraising database package:

• The built-in fundraising functionality: this has to be number one. These guys have been selling fundraising databases before Salesforce was a twinkle in Marc Benioff's eye. And as such they have rich and comprehensive built-in functionality for fundraising. It's why they were created in the first place. And even the more thorough templates/apps which are now available for Dynamics and Salesforce are hard-pressed to match all the fundraising functions which the fundraising packages can offer - and some don't even claim to be more than a starting point. Some of them are getting closer of course...
• The suppliers themselves: This is almost as critical as the functionality - in fact, sometimes I would put it above the functionality for a reason as to why you should consider fundraising packages. Because the suppliers have years and years of knowledge of working with charities; they have staff who will have hundreds, even thousands of hours of experience which they have gleaned from the NFPs they have worked with; they have the heritage of working with the sector; and many have hundreds, even thousands of existing charity customers who already use the software, have provided feedback (good and bad) and who, believe it or not, may actually even like the software!
• Reduced risk of the implementation itself: Some of the more critical aspects of a fundraising database implementation are aspects such as direct debits, marketing selection processes, finance/donation structure, gift aid and so on, and these are the areas which the packages already have ticked and, as importantly, have implemented many times in many different environments. Even the better CRM systems still have limited exposure to such areas and are still learning. This does reduce risk. Equally, the wider functionality already available means you have a structure to the system and the implementation, you will be able to run your processes in proven ways and you won't just forget some functionality. Plus, the suppliers have done it all before many times and it's even quite feasible that some of your staff will even know the new system from other places they have worked.

All that said, and to keep things in perspective, I do realise that some of these benefits I am promoting could equally be seen as downsides by CRM suppliers, and some CRM suppliers could quite rightly point to their successes; so do remember I am just saying here why the traditional packages should at least still be considered...

Could a Business Case be Presented as an Infographic?

Recently,  Econsultancy.com reported how The Bill & Melinda Gates Foundation had produced its annual (2014) letter, written by Bill Gates himself, as an interactive letter supported by poignant infographics, and as a result it doubled its reach. Last year, Cancer Research UK published their annual report as an animated infographic (see below). And very impressive it was too.

Both of those cases got me thinking: could I use the same idea for presenting a business case for a new fundraising/CRM database?

I thought of this because I have sometimes found that trying to distil what is really important and key in a business case in a simple and concise way can be very difficult. (And yes, okay, I know verbosity is one of my personal problems… but even so). We try to add Management Summaries and a list of key bullet points, spreadsheets with the key figures, even a few charts/graphs, but sometimes it still doesn't seem to be understood by all the people who matter.

So maybe an infographic could do the job better. It would ensure we really had to think about what the most important points are, as you can't have a 20 page infographic, and it would hopefully make it far more visible, easily digestible and, importantly, quick and easy to understand. If necessary, you could even have 3 or 4 infographics - say, one for the key business drivers, one for the benefits, one for resources and one for costs. I would still keep them as concise as possible but that might mean you didn't try to cram too much onto one infographic.

You might still need a full business case document to back this up, but when you only have a few minutes to persuade your manager or board of trustees just why you need a new CRM system and why it is going to cost just a tad more than you had originally thought, then maybe this could help.

Anyone want to try?

- - - - - - - -

CRUK Infographic

Data Migration: It won't make an implementation succeed on its own but a bad migration can make it fail

 

In almost all fundraising and CRM database implementations, there will be some element of data migration - getting data out of your old database and into your shiny new one. But that isn't easy. Data migration takes time, skill and a knowledge of not just the new system itself but of how you are going to use it at your organisation.

And although data migration is not the most important thing in an implementation, it is still a very important thing. Hence: although data migration won't make an implementation succeed on its own, a bad migration can make it fail.

One of the problems/risks with database implementations is that it can start to be seen just as a data migration project. We lose sight of the benefits and process improvements and all the other good stuff we wanted to do with the new system and it just becomes an exercise in forcing the damn data from the old system into the new one. It's an easy thing to do. Try not to let it happen to you.

What you should be doing is running the 'functional and business process' stream(s) in parallel with the data migration. There may of course be some data which is comparatively easy to map to the new system (i.e. name, address, hopefully basic cash donation fields) and that can be done early on in the project; but as much of the project will be taken up with deciding how you are going to use and configure the new system for your organisation, then the data migration needs to reflect that - not the other way round.

I've seen good data migrations with good implementations; I've seen good data migrations and still seen the final implementation struggle, but I've never seen a bad data migration and a successful final implementation. Consider it carefully, spend time on it, get it right.

Why non tech people should apply for (so-called) tech jobs

 

The three best database managers I have worked with at charities over the last 15 years all have one thing in common: none of them would call themselves a techie. One started her career with horses, one in a press office, another did a humanities degree. In fact, I have found again and again that people who studied humanities seem to make good database people.

And I would love to see more people who are not techies move into the "database arena", for want of a more all-encompassing phrase - yes, even fundraisers! There are several reasons for this:

• There are more and more roles in "database teams" where it is far more important to be business savvy, fundraising-aware, have an understanding of marketing and to be knowledgeable as to what the charity wants, than it is to know what field or function to use in the database. That can be worked on by other database team members and/or learned by the non-tech person.
• There are so many similar attributes which non-technical roles have which could help database teams: communication skills, analytical skills, attention to detail, insight, understanding of specialist areas such as direct marketing. Specific database skills can be taught - the soft skills are far harder to teach.
• Data knowledge does not necessarily have to mean database knowledge. The database is nothing without data - that's the lifeblood of the database. So if you know/like/understand/find data interesting, then you are half way to being a data(base) person.
• The best database trainers are not the ones who understand SQL - the best ones are those who can relate to the fundraisers.

I would love to hear from anyone who is now working in a database team who came from a non-technical role and/or where they did not/still do not consider themselves to be a tech person. Do give me any feedback in the Comments below.