How to Work Around Workarounds…

 

When doing a recent migration project to a new database, the following issue became very obvious several times during the project - an expression which generally depresses everyone: "we have a workaround for that…" And whilst I know that sometimes workarounds are (or at one time were) necessary, there is one particular instance of such practises which I feel could be better addressed:

This is, ironically, in mid/large charities with multiple teams, where one specific reason for creating workarounds (and yes, by that, I sadly often mean creating spreadsheets…) is because an individual fundraising team feels - rightly or wrongly - that they have not got the necessary support/input from the database team; and so by introducing the workaround, that is the only way to achieve something which they have to do. So they create their workaround and, before you know it, that has become the accepted (if still annoying) practise within the organisation.

In such instances, whatever the reason it did happen in the first place, whether it was because the database team at the time couldn't help (maybe through under-resourcing or inability) or even if it was because the individual fundraising team was bloody-minded enough to do it without any proper consultation of the database team, it should no longer be just accepted as the right process to follow. We need to find out if the workaround can now be resolved and got rid of.


So what's the answer?
If such a workaround is now semi-permanently in place at your organisation, the answer is pro-activity. Either from the database team or the fundraising team.

Pro-activity on behalf of the database team if that's appropriate: discussing the situation with the fundraising team when you find out about such an instance, understanding the problem, planning what you can do, and then with realism and pragmaticism, suggesting a new approach which will remove the workaround. Don't blame people or say how bad the old system was or someone was, just approach it from the point of view of showing how you can now fix it. That's what people want to hear.

Or pro-activity on behalf of the fundraising team if they are the party who feels that the database team are not helping enough. Again, recognising that the database team might be stretched, but emphasising how much a change would help, offering help if appropriate, possibly suggesting how the same process is done at another charity with the same database as you (although you need to approach that carefully in case it gets the back up of some database managers!) or maybe even having to accept minimal compromise to ensure the bigger picture is improved.

And yes, I know that everything I have written here is sometimes easier said than done, and that it's likely that both teams - all teams - are always busy, but addressing horrible workarounds like this can be one of those things which really can help everyone and truly improve efficiency.

Curb Your Coding Keenness When Creating CRM

If you are implementing a CRM system, then, as much as possible, I would recommend that in the first instance you don't use "code" - or limit it as much as possible anyway. I know I have written about this before (Learn what your software can do before customising and changing), but it is such a useful, fundamental thing to remember, and there are so many more charities now considering and implementing CRM systems, that I wanted to re-iterate it again here.

To clarify: one can configure a new database, which is clearly essential and highly beneficial, but this means using existing tools and functions in the system which, for the most part, can be managed by just the software's "front-end" interface (i.e. drag-and-drop, using the standard GUI and the like). Indeed, some CRM systems can do this and still provide very sophisticated functionality and capabilities.

But as soon as you start writing code, "customising", bespoking a system, then that is what I would recommend you try to stay clear of, at least when you are first implementing a new database.

Why? Because customising takes longer, is more complex, needs more work, raises the risk factor, it will cost more, requires more specialist expertise, will be harder to change later, will be harder to maintain later, you may change things you will later learn you didn't need to change and so on.

Of course, there are good reasons for when customisation can bring benefits, such as automation, simplicity to end-users and integration, but I would always challenge exactly why this is planned in any instance. Just what are the benefits/time-savings/efficiencies? Can it really not be done another way, at least in the first instance? You can always do the customisation later if you later decide it really is worth it.

And if such discussions mean that coding/customising is shown to be a beneficial thing then great, let's do it. If not, keep it simple, configure the database, use a process and move on. Your project manager will thank me. And so will your FD.

Which database is best for a Solo Fundraiser?

Following on from my previous post about What is the best database for a small distributed charity or a solo fundraiser? this post considers what the difference might be for a charity who only has a solo fundraiser. However, my previous post addresses the fundamentals of any such decision even for solo fundraisers, so if you haven't read that yet then do so first.

The main additional points for a Solo Fundraiser to consider are as follows:

• Are you working for a small charity who does have an office and, if so, then do you already have an on-premise server? If so, then you can look wider for any system which might meet your needs as it doesn't have to be hosted/SAAS. You might still of course want one of the hosted/SAAS systems already mentioned in my previous post, but additional examples of such systems you could consider compared to the ones from my previous post are Donor Strategy, KISS Software and Harlequin Software.
• Even though you are a solo fundraiser, is it likely that the charity could grow in future? If so, then most databases should still be sufficient for such instances, but just don't forget or assume that.
• Even though you are a solo fundraiser, do you actually work for a larger organisation with more complex requirements? In which case, it might be that the very simplest fundraising database might not be applicable to your needs. Hard to quantify, but don't just assume therefore that a low-cost option is best for you. For example, I do know of some charities who have even bought The Raiser's Edge for a solo fundraiser, but in this sort of instance, that is more when they have good in-house IT support, when a fundraiser knows that sort of system and often when they are planning to grow later. (NB Clearly, other databases similar to The Raiser's Edge have also been installed for solo fundraisers - I use The Raiser's Edge as an example because of its wide awareness and to emphasise the point that it does need more support and consideration when implementing it).
• As no-one else is going to be using the database initially (although I realise some places might have the odd, additional manager also viewing it at times), you really do need a system which does not require complicated management. The difference here to the 'small distributed charity' is that that charity might very well have a few people using it and might be able to justify better the input required to manage it for the whole organisation.

And do remember the other advice I gave before: I'm afraid it isn't as easy as just plugging in the system - it will take time to set-up, even if there is only one of you!

What is the best CRM Database for a Small distributed charity or a solo fundraiser?

 

A couple of questions I am regularly asked are: "I am looking for a CRM/fundraising package for a small charity with no central office. So, no server and we probably need something to work across Windows and Mac." And it must be simple to use... Similarly, "What is the best database for a solo fundraiser?" So, I thought I should try to answer these questions here. I will address the 'small distributed charity' first as much of that applies to solo fundraisers too, and then add a shorter, second post with additional details on databases for solo fundraisers.

First: Get your main IT infrastructure sorted out
This is important. Especially if you don't have a central office, and the route you take may partially influence your decisions on which is the best fundraising/CRM system for you. So, first of all, if you haven't done so already, make sure your email system, file access, website etc are all part of a solid strategic approach.

Second: Remember, it's still important to know your fundamental database requirements
This is the same for any database procurement and just because you are a smaller organisation doesn't mean you should completely ignore it. So do document what you want the system to do, even if it's just in a brief Word document. That will help you focus on what is most important to you and you can then weigh-up the system options later. And remember, whatever database you buy, the data you put in it, the business processes and training you put behind it, and the fundraising strategy it is supporting are all more important than the software itself. You can have the best database in the world but it won't help if your data is rubbish, you don't adapt your processes and so on.

You also need to bear in mind just how much time and effort you can or want to allocate to managing your CRM/fundraising database. Remember that all systems will require some initial work, regardless of what the salespeople say! You will have to consider the configuration, maybe data migration, how and where you are going to store your data, how external data files will be loaded, how training will be done, how you will maintain look-up tables to ensure good data consistency and so on. And even though you are a small charity, there could still be a number of people who might well want to access and use your database, especially if it is not just for fundraising. In which case do remember the need to have someone who is data/database savvy so that they can manage these issues.

All that said, I do realise that for many small organisations, your requirements will be similar and comparatively fundamental, so I will use that assumption in the rest of this post. Plus, I am restricting examples of systems to those which should be within the budget of a small charity.

Oh, And it Must Be Simple to Use...
This is possibly one of the most frequently used statements which small (and large!) charities use. So it is important to realise that CRM and fundraising databases are not as simple conceptually as Excel, Outlook etc. They will take time to learn, they will need some looking after and the likelihood is it will cost money to do all that. Sorry. There is no easy answer to that. Software is getting easier to use and more intuitive but at the end of the day some of that is still down to individual preferences and interpretation. Just don't under-estimate the work involved in getting going if you haven't used a CRM system before.

Two technological approaches: Hosting and SAAS
Fundamentally, you have 2 technology approaches which may influence which databases you consider, and which technology is right for you will partially depend on your IT infrastructure. ¹

SAAS stands for Software-as-a-Service, where a supplier provides a database which you can access as simply as gmail etc, and from any browser without the need for any additional software. Most such solutions are only offered this way (with a few exceptions); i.e. not with an alternative "on premise" option.

Hosting is similar but one-step removed, where your database will be "hosted" on a remote server in a secure data centre somewhere (i.e. you still won't need a server in your own office to make this work). This is usually done for software which has not been written specifically to run directly through a browser and thus it still needs to be stored on a specific server somewhere. Thus for hosting, a supplier will most likely host the database on the supplier's own server and you access it remotely from your office/home. (Additionally, most such suppliers will also offer clients the option of letting you install their database on your charity's own server).

In theory, you could take any fundraising database and host it on your own server anywhere - but to do that, I would recommend that you need to have taken the IT infrastructure route which already supports that. i.e. you are already using a company to do this for some/all of your other files/software applications.


Examples
Examples of SAAS databases are Salesforce, Microsoft CRM Dynamics, Workbooks and companies offering 'templated' versions of these. Plus, fundraising systems such as eTapestry or DonorPerfect.

With hosting, you have a wider option of solutions. As I mentioned, you could look at almost any database, but some companies already offer Hosted solutions as part of their portfolio, mostly through third-party partners; e.g. CiviCRM, Advantage NFP, thankQ. (Remember these are products more applicable to small charities - there are many more options for larger organisations).

And if as a small charity you have more severe budgetary issues, then the following posts I have written before might also help you: What should you do if you really have zero budget for a new CRM or Fundraising database? and Why Free Software Doesn’t Mean Zero Cost.

---

1. More technology-savvy readers will no doubt realise I have greatly simplified these descriptions, so please forgive any gross over-simplifications! If you feel I have really misrepresented anything then please let me know by email or in the comments below - thanks.