End Thought for 2010: Keeping it Vanilla

There has been a common thread amongst CRM implementations I have been involved with this year, and on various other blogs I have read and conferences I have attended: keeping your CRM implementation Vanilla.

This is an IT/CRM term which may sound vaguely amusing if you have never heard it before, but it is one of the more important things you can consider when procuring and implementing a fundraising/membership database or charity CRM system. What it means is that, as much as possible, you implement the database in the first instance without any - or with minimal - “Customisation”; although “Configuration” is fine. (NB: All packages will allow “Configuration” to some degree and if they don’t then don’t buy them).

Why is Vanilla so Important?

Why do this? Quite simple: it will improve the simplicity of implementation, lower risk, create a faster implementation, a lower cost implementation, there will be less need for specific/expert resources, it will be a simpler and quicker data mapping from your existing database, enable simpler testing, you’ll avoid scope creep and more. All these things will mean that your initial implementation will be smoother and have a far higher chance of success. If you are buying a powerful or flexible database then it will be immensely tempting to jump straight in and implement lots of exciting Customisations from the word go, but if you do then you may not receive those benefits listed above.

Defining Configuration & Customisation

So having said that, I should define the two key terms: Configuration and Customisation. These are my definitions below and even if you or some suppliers don’t agree with all my points, the heart of the message is the same. Different suppliers will define these differently and claim different things, so at the end of the day, you need to discuss these issues with any prospective supplier and understand, in some detail if necessary, just what you can and can’t do in each of the following areas.

Configuration. It is Configuration if...

• You use an application’s built-in tools to make changes to the system which every other organisation using this package could do and recognise if they were to start working at your charity.
• If an upgrade/new version of the package was released tomorrow, then you could install it without worrying that any of the Configuration which you had done would mean that the upgrade wouldn’t work, and equally, knowing that the upgrade would not affect any of the Configuration you had done. In practise, some upgrades might still require some such work so if that is the case for your system then do spend time to understand just what that it is. (And of course, whatever the case you always need to test upgrades anyway before going live with them.)
• The changes could probably (if not always) be expected to be done by a “non-techie”. This doesn’t mean an un-trained person and it doesn’t mean a non-database savvy person, but to put it in perspective, I wouldn’t normally expect Configuration to require any programming/coding, i.e. writing code in VBA, XML, C+ etc. This might not always be true but as soon as you do get to this level of “Configuration” then in my experience it is likely that you are starting to get to “Customisation”. Either way, ensure again that you know the impact.

Customisation. It is Customisation if...

• The implementation involves bespoke changes, new modules, hard coded programming etc which the supplier or a third-party does for your organisation for your specific needs. 
• If the work does mean that upgrades/new versions are affected (either because it stops them happening or because your Customisation would need additional work to be done on it).

So should you ever consider Customisations during an implementation?
It is of course very easy for me to write this and say that you shouldn’t do Customisations but do I think you should ever consider Customisation during an initial implementation? Of course you can! Consider but always ask yourself if they are definitely needed. But if you have a critical business function which is required immediately on go-live and there is no other way to achieve it, or you will get so much benefit from a Customised approach that it just makes sense, then go ahead, see how you can implement it. In particular, if a Customisation only has an impact on an “isolated” part of the system (or as isolated as one can expect in a CRM system), as opposed to a core area then that should lower the risk. One thing you could also do to mitigate some risk would be to discuss with the supplier whether could they take your proposed Customisation and build it in to their standard product in a future release.

And do remember that you can of course implement Customisations later, after your initial go-live. Why is this better? Because you can implement them in a more structured way, at a better pace, spreading costs, with less risk, increase user adoption and do it as you learn the package and all its capabilities. In fact, as you gain knowledge of the package, you might even find that some complex Customisations which you were planning originally can be greatly simplified or might not even be needed at all. Don’t shy away from those which are needed or which do bring you benefits, just take them on at a pace and structure which you can implement more easily.

Are there downsides to this approach?

All that said, let me also say that if you do follow my suggestions here then there may be downsides, or at least issues to overcome, for example:

• End-users will (hopefully) be excited by the prospect of a new system, and if they have been sold-on and told about all the wonderful new, whizzy things it can do - which require Customisation… - and then find they are not included when they first get to use it, then they might be disappointed and user acceptance could stall; especially if that doesn’t improve their processes or, say, some screens/forms are not as they would ideally want. So you need to address this early on during an implementation and explain to the users exactly what they are going to get and when – and why you are doing this - and ideally give them a roadmap as soon as possible for future developments of the implementation to show when they can expect the elements which do require Customisation. 
• Those great Customisations you planned for later never quite seem to happen… This is one of the higher risks of this strategy if you do not build-in a structured approach from the word go, especially for charities, where money is often tight. If you are not careful then what you start with will be seen as perfectly okay and if it's working then why do we need to do more work on the system anyway…? To avoid this, ensure you explain and discuss your proposed approach with your Senior Management Team/budget approvers early on in the procurement or implementation phase and get their full support and a committed budget for the post-live Customisations.
• And just to re-iterate what I said above: if you do require a specific function and Customisation is the only option or the best option, then don't shy away from it.

Remember, Vanilla is not boring, it’s a great flavour because of its simplicity!

How to Stop Duplicates from Getting into Your Database

I’m starting this blog post by saying I was tempted to just write “You Can’t” and leave it at that! Thus you will see that there is no perfect answer to stopping duplicate records (a.k.a. dupes) from getting into your system, but that is no reason not to try and so I hope that the following will help you.

The first thing to confirm, therefore, is that it is almost impossible to have zero dupes in your database. This may be because of human error, unknown pieces of biographical/contact information, individuals not updating you with changes of address, individuals giving you different personal details on different occasions, or from technological problems such as poor database structure, lack of data integrity or weak duplicate checking tools. And data degrades. Fast. Millions of people move address every year and data management and data quality considerations on databases often slide after any initial implementation.

So first, consider how you are inputting new records and the different sources. You almost certainly will be doing some manual data entry and it is quite probable you might also be importing new records electronically, for example from a fulfilment house, your web site or another system within your organisation. Secondly, don’t forget that is not only when you enter new records when you might be creating a duplicate; updating records can also create dupes, and again this might come from manual keying of data or from loading data from an outside source.

The first line of defence against dupes is actually a simple one: user training. Make users aware of the issues of creating dupes and what it can mean to your organisation. Train them how to check for dupes, how to enter data consistently and accurately, how to ask for full and accurate supporter information and so on. But of course they can forget or do it badly or the name/address details may be too different/complex for them to be able to find a dupe simply, so don’t just rely on this approach.

Secondly, if you haven’t already, consider if there are ways of improving data integrity and accuracy through the database technology you currently have. For example, if you store counties, ensure they are in a look-up (a.k.a. drop-down) table; limit post code fields to 8 characters (ideally, check the data format!); split the name fields; and help users check for dupes by enabling them to use “wildcards” when searching for existing records. (e.g. w*wright will find Wainwright, Wainewright, Waynewright etc).

The next thing to have is a duplicate record checker which is native to your database and which is automatically invoked when you add/update records. At this point of data entry, you actually want such a check to be “broad” rather than “100% precise”. i.e. when you enter a new name and address, you don’t want the system to check for an exact match on all such data fields. You want it to be able to check whether there could be a duplicate record based on some of the criteria you have entered. Take my name for example: Ivan Wainewright. If you keyed a new record from me but forgot that my surname had an e in the middle, then an exact check would not find me. So, the dupe checker should check on a set number of characters within a name and address fields.

Ideally, such dupe checkers should even use fuzzy matching, something which the latest Enterprise level of SQL Server now comes with as standard. i.e. With fuzzy matching, a dupe check should find my surname with or without the e, and if I had a vanity address (e.g. Rose Cottage, 1 The Avenue etc), then it should be able to account for that too. It’s a pretty powerful tool and well worth using if you can.

But when you import data electronically you need to consider dupes slightly differently. If you have thousands of records being imported then clearly you can’t check each one by hand. But if you do want your import process to merge dupe records automatically, then in this instance, if you have too “broad” a dupe check then you could end up merging two records which the system thinks might be the same but which may well not be. And there isn’t a much worse thing to do in terms of supporter management! So, for electronic imports, you may decide that you do need a 100% match on data items (or as close to 100% as we can ever really be) in order to know that there is an existing record on your system; or maybe even consider asking for human interaction on a limited number of records which the system cannot definitely match but where it reports there could be a dupe.

Specialist software can also help with all of the above, the most common such system being PAF software, which will help you add and update addresses accurately by using the Royal Mail’s post code system. It isn’t the cheapest of options if you need many licenses but it’s well worthwhile. (And you might only need such software for users who do add/update biographical data). You can also get online PAF systems to help with data entry on web forms.

You might also want to consider using email addresses and mobile phone numbers as additional dupe checks; just because someone moves house doesn’t mean they get a new email address or mobile number, so see if that can help.

You could also introduce a supporter self-update system on your web site which supporters can fill in if they change address. And if they do then remember, there is very little which is more indicative of a keen supporter than someone who pro-actively tells you they have moved house. Treat them well! And if you do collect data online/electronically, whether it is on your web site or through a third-party, then it’s clearly going to be more accurate if you can add it to your central database electronically rather than re-keying it.

But despite all your best efforts, it is highly likely you will create dupes, so you also need to have a regular data cleaning protocol. Again, your database may be able to help by running a duplicate record report on your records (and at different ‘levels of confidence’ so you can automate some merges and check others manually), and/or you can extract your data to analyse and check it outside your system. There are plenty of good dupe checking software packages and there are lots of agencies and companies who will help you clean your data. You can also use services such as the NCOA (National Change of Address) register to check for people who have moved house and thus identify dupes that way.

And a final thought on a far too common issue for charities: if you have multiple databases in your organisation, then, amongst all sorts of other problems, if you transfer data between them then you can significantly increase the likelihood of dupes – cut down on multiple databases whenever possible.

Getting Data Out of Your Database

I still come across too many database implementations where the users simply cannot get the data out of their system unless they have a degree in rocket science (well, a qualification in normalisation and ER diagrams at least), and even then, it doesn’t always give them what they want. And it is such a fundamental aspect of any database that it negates half the purpose of implementing the system in the first place: so many of the benefits of a database come from reporting, analysis, querying, mailings, data extractions, segmentation and so on, so if you can’t get the data out of your database then what is the point of having it?

Remember this incorporates two key elements: obviously, the creation of the actual reports, mailing fields etc is one, but the ability to select and segment on the required records/data is another. Even if you can get the necessary data fields out of the system, you still have to be able to extract/report on just those records/supporters which you are interested in on a specific occasion. That is an area which some systems still fall down on unless you do have technical skills.

So what you can do about this to prevent this from happening?

The ideal scenario for most small to medium (and many larger) charities and NFPs is that trained users – there will always be an element of training – can get the data out of the system for many of the above purposes, at a fundamental level at least, without recourse to an IT/database expert. That usually means having a GUI approach (Graphical User Interface) of some sort (i.e. rather than having to write SQL) and/or having flexible enough reports and screens that are parameter-driven so that users do not have to understand how the data is stored or structured. They clearly still need to know where the data is stored, in which fields, and how the data is used but not so they have to know any programming skills.

Such interfaces might be native to the product (perfect if they are flexible enough) and if a product has a good built-in report writer and query tool then that is a great option. That said, the key word there (rather obviously) is “good”, because if it still can’t extract the data the users want then it may as well not be there.

An alternative, and often still a good option for flexible data reporting/extraction etc is through a third-party reporting/analysis application which can access the database; e.g. Microsoft SQL Reporting Services, Crystal Reports, QlikView. Such tools do vary in their level of ‘technical knowledge’ which a user needs, so you need to choose carefully to ensure your users are comfortable with whichever product is selected.

Ideally, the database supplier would bundle such software with their system so that it is integrated ‘tightly’ enough in order that there is minimal additional work needed by the users to get the data integration aspects set-up and then use the data. Or at least provide documentation on how to integrate with their table structure. Even Microsoft Access query tool is a start – it leaves plenty to be desired, and there are better ways of querying a database - but at least you don’t have to know SQL..

Extracting all data

But even if the above is not possible (and actually, in most cases, even if it is) then the system must at least allow you to be able to do a straight forward data export of the data into another system where you can query it and use it further; e.g. Excel, Crystal Reports, SPSS and so on. And again, ideally by selecting the data and records through a native interface within the database. The problem with this is that very often extracting data from what is probably (hopefully!) a normalised database into a “flat file format” means data manipulation in another system can be complex and time-consuming because of “duplicates” created from “one to many relationships”.

But if your database can’t do that, or if it only offers limited tools or limited access to particular data entities, then you may need to resort to using SQL to enable the reporting, analysis, segmentation et al. But that means having serious IT skills and also learning and understanding the underlying database structure and that is not always easy if you didn’t design it yourself. Certainly it is not for the faint of heart and I sympathise with anyone who is not an IT person and has to do this.

The other critical factor…

However, even after saying all that, and even if you can get to the data in one way or another as per above, then there is another critical factor which must be considered: and that is that you must be able to access, query, extract, report on any item of data which you are storing - and unfortunately, some database packages do not always allow this, which is incredible, frustrating and very disappointing. If you are using SQL then that shouldn’t (?!) be a problem, but if your database has its own native analysis/extraction tool, then it isn’t always the case. 

So if you are looking at procuring a new database or you are about to take over the management of an existing system, or even if you are a fundraiser who would like to ensure that they can access their data in a useful and meaningful way, then do ensure that you can get the data out of the system as well as getting it in.

Top 50 Database Procurement Tips for Charities and Not-for-Profit Organisations

I have been tweeting my Database Procurement Tips for charities and not-for-profits over the last few months, for all sorts of databases from  fundraising and membership databases, CRM systems, or a bespoke development. So here is a collation of my first 50. Note they are not in any order of importance; the numbers simply (hopefully!) make the list more readable.

I will be tweeting more tips in the week and months to come so if you want to see them then follow me on Twitter.

I hope they are useful!

1. You must do an internal needs analysis before looking at software
2. Make sure you allow a budget for hardware and IT infrastructure costs
3. Create a business case before looking at software
4. Ask the suppliers to bring a support/implementation staff member to the demo, not just a sales person
5. If you create an ITT, don’t just ask yes/no questions, but get the suppliers to give fuller answers to some questions
6. When comparing costs, use a Total Cost of Ownership cost model: i.e. not just the software but all costs
6a. When comparing TCO, do it over 5 years, not just the initial procurement costs
7. At the demo, ask the supplier what weaknesses their software has…
8. Get your users involved in the needs analysis stage and keep up the communication
9. At the demo, try phoning the supplier’s help desk live and see what sort of response they give!
10. Ask for costs in a structured way on your ITT/RFP so that you can compare them more easily

11. Remember that the software is just an enabler – find out how aware the supplier is about understanding your business
12. At the demo, ask the supplier what their software can’t do. Could get some interesting answers…
13. Don’t cram too many supplier demos in one day – it’ll kill you and you simply won’t get the same benefit from them
14. Ask the supplier what they think the key risks are for your project
15. At the demo, ask all suppliers to show you the same things, so you can compare more easily
16. At the demo, make sure you see how you could create reports, do queries, create mailings – get data out of the system
17. If you create an ITT, incorporate it into your contract with the supplier
18. Ask the supplier what experience they have of fundraising, or what they believe the latest fundraising trends are
19. Never under-estimate the costs and complexity of synchronising data across multiple databases
20. Ask to see the suppliers’ roadmap for future developments. If they haven’t got one…

21. Be careful when suppliers talk about Workflow – it can mean different things to different men
22. At the demo, ask the supplier for a reference who used to be unhappy with them but who is now a happy client
23. Ask whether you can segment the database on any and all fields you have in the database, including user-defined fields
24. Consider how to integrate the database with your web site. This can be one of the most costly and time-consuming elements
25. Find out how flexible the system is for importing data from different sources
26. Ask for system requirements and performance figures for at least twice your expected record numbers
27. Don’t under-estimate the time and effort needed for data migration
28. Find out from the supplier exactly how they will help with data migration & what their experience is
29. Purchase time is the best time to get discounts, so if you expect to increase your licenses later, bargain now!
30. Check whether future upgrades are included in your annual maintenance costs

31. Don’t skimp on training costs
32. Ask the supplier for their project management approach, but don’t rely solely on the supplier for this
33. Ask the suppliers how they provide bug fixes
34. Ask the suppliers how they train their own staff
35. Ask the suppliers how they manage Quality Assurance within their organisation
36. Consider the cost of decommissioning your existing database
37. Remember to include the cost of third party apps in your budget, e.g. PAF software, banking sw
38. Don’t expect your data to magically be cleaner or more accurate just by buying a new database
39. Ask the suppliers for their experience, input and recommendations of change management and your new db
40. Consider the option of asking 2-3 short-listed suppliers to prototype a specific element of your requirements

41. Never base a procurement decision on just software, just costs, just the salesperson…
42. Consider visiting a supplier’s offices before you make a final decision
43. Ideally, talk to a number of the supplier’s references, not just one or two
44. Ask the supplier if you can attend one of their user groups before you actually buy the software
45. Ask the suppliers how they recommend you create and structure your implementation project team
46. Ask the suppliers directly what costs are not included in their quote
47. Ask the suppliers why they have lost customers in the past
48. Ask the suppliers how many new clients they have added each year for the past 5 years
49. Don’t expect the supplier to provide a fixed price on data migration until they have seen your data
50. Ensure you have your fundraising/membership strategy in place before buying a new database

Thanks for reading. If you found these tips useful, then you can get more in-depth advice on this area in my eBook. Click on the image below to see more information on that.

Can I Use Microsoft Access for my Fundraising Database?

As I am asked this question regularly, I thought it would be useful to give my thoughts in this blog. So, the short answer to this is yes, you can use Access for your fundraising database, but that doesn’t mean you necessarily should. As I have blogged before, if you want a fundraising database then my initial response would always be that you should look to see if an existing fundraising package could meet your requirements, and frankly, I would be surprised if one couldn’t for the vast majority of charities and NFP organisations.

But if you are determined to develop your own fundraising database, then yes, Microsoft Access can of course do the job – as can other similar development platforms such as Filemaker and MySQL.

And as much as many people (love to) criticise Access, it isn’t that bad a development platform, it can be simple to create a comparatively simple database and if you only need to use it within one office for a few people then it can do the job. There are some templates available on the web which can get you started, there is a book which might help you, written some years ago by Peter Flory on how to build a fundraising database in Access or similar systems, and because it is so widely used, a benefit of Access if that if you have a bespoke database developed by one person then, in theory, someone else could help you change/further develop it at a later date. Indeed, there are many independent Access developers who do regular work with charities. That said, it is never easy picking up someone else’s program unless it is extremely well documented, both within the code and outside.

But be aware of its key shortcomings too: it isn’t really suitable for large volumes of data (even tens of thousands of records can affect system performance), it isn’t automatically web-enabled (so you can’t access it from home or remote offices just like that) and of course it still requires all the design and development work which any bespoke system would. So it isn’t free!

So I repeat, yes you can use Access for a fundraising database but please consider all the other options first.

What does make CRM software user-friendly?

In almost all ITTs I have helped with, the client has asked that “the database software must be user-friendly”. But what does that really mean? Is it such a personal thing that no database package can ever be fully user-friendly for all users? And who should it be user-friendly for? Just the end-user or the database manager/technical staff as well? Can we really define user-friendly? Well, I’ve seen a few CRM packages in my time, the good, the bad and the really ugly, so these are my top requirements for user-friendly database software:

• Screen layout

o       This is generally what people think of when they mean user-friendly. Clearly, screens (forms) should not be too busy - don’t cram fields together on one screen, keep it ‘clean’, keep common fields together on one screen/tab, don’t use really small fonts. It’s all common sense but unfortunately it isn’t always that common.

o       Screens should ideally be customisable for different users/types of users. This can really help: why would the DM manager want to see the same fields or menu items as the volunteer assistant? And no end-user wants to see all the hundreds of icons which the database manager needs to see, so don’t display them to such users.

o       List columns can be changed by users using click-and-drag. A very specific point, but databases inevitably have lots of forms with lists of records and ‘one to many’ type entities (which when clicked on, show much more information behind them); so if a user themselves can simply change what is important to them on such lists, and continually change that if their requirements change, then that can really help user-acceptance.

o       Not a clunky look-and-feel. Okay, that’s hard to measure and a little obvious but I have seen some dreadfully clunky systems even in the last few years and there is nothing more off-putting as a first impression.

• Overall navigation

o       Standardisation and familiarisation. There is little reason not to use a standard approach for the look-and-feel of a package’s general navigation. Whether it’s the familiar Windows/Mac environment, an “Outlook look-and-feel” (e.g. MS CRM), the use of browser/hyperlinks, good use of double-clicks, and increasingly, the ability to click-and-drag a la Google maps/finance graphs etc.

o       Consistency across the whole package. Please!

o       The ability to add ‘bookmarks/favourites’ (as per web browsers) so that, rather than having to remember which 4 clicks are needed to get somewhere, common functions and records can be accessed from a user’s front/home screen – especially on feature-rich databases and those with multiple screens and icons.

• Customisable terminology. Users love to see terminology they are used to. They don’t want a field which says ‘region’ if their organisation uses ‘areas’. They don’t want a ‘donor analysis & performance report’ if they run weekly ‘donor update’ reports. There are limits, of course, and packages are still packages, but the more an organisation’s own terminology and language can be used, the more user-acceptance you are likely to get.

• Automation: automating tasks can be extremely beneficial. Mostly in processes (e.g. when sending a mailshot, the ability to do the mail merge and update the communication history on a donor’s record – all using one click), but also in terms of data integrity; if you enter ‘Mr’ on a supporter’s record, then surely the gender should be ‘Male’.

• Simplicity when creating queries/reports. This is one area where the trade-off between sophistication and simplicity may be difficult. It should be possible to use a GUI to create simple ‘list’ type reports, and I like the ability to make reports parameter-driven so that a user can learn how to use just one report but run it against multiple sets of records or for multiple scenarios. But when it comes to more sophisticated requirements, there is no getting away from the fact that a report needs to be created by an experienced/database-savvy individual – but hopefully they can make that available as a simple report for the end-users. No SQL for end-users, please.

• Intuitive. This is the second-most common request by organisations, that the software “must be intuitive”. But this is so different for different types of people, for different levels of skills, for people with different experience of databases and so on. I would say that if much of the above can be met, then the intuitiveness of the software should follow. But that doesn’t mean you won’t need training…

• Other points:

o       Simple integration with other packages: Word, Excel etc. Yes, great. One-click to make a report into a Word or PDF document; right-click to export to Excel.

o       Speed? A lightning fast database won’t make the software automatically user-friendly, but a slow database sure can make it feel unfriendly.

o       Easy to update. One for the technical guys and support staff (and implicitly the end-users): if software updates can be centrally deployed rather than having to go round each PC with a CD…

o       Small, specific features can really help. Just a few examples: the ability to drill-down in reports (to further levels of the report or even into supporter records), predictive text on drop-down fields, simple moving between records/opening multiple records at the same time, colour coding for specific records/statuses. I’m sure you can think of others. 

o       Help screens? Even better if they are customisable by a client. Good error messages?

It is interesting that when considering much of the above, one does need to consider the pay-off/difference of user friendliness for end-users as opposed to database managers/the technical staff. It may take a database manager some time to make the database terminology correct for their organisation but it will help the end-users enormously; they may need to create multiple versions of a form for different groups of users, but it should cut down on their support calls. 

And what of the future? Is the iPhone generation going to change the way CRM databases can be used? Is touch-screen the future? Or voice control?! Basically, if the software is simple (okay, that’s still subjective), customisable and follows standards then that’s a good start, and our desire to minimise everything to the size of a mobile phone should still reflect that.

A CRM Database Doesn’t Mean You Can Now Do CRM

This is a brief, simple message: just because you have a CRM database does not mean you can automatically "do CRM". CRM (Customer Relationship Management) is not about software – CRM is a policy and a practise and a whole culture – not (just) a database. In fact, it is possibly one of the most abused terms in the IT industry and has been used to describe so much software that a few years ago had a completely different moniker.

That said, the good news is that if you are a NFP organisation then it is highly likely that you already practise good CRM – if you look after your clients, manage your donors, communicate well with your supporters then you are more than half way there. I believe that, in some ways, charities have been ahead of the commercial sector for years in terms of “CRM”, as charities have always known how important it is to look after their supporters and stakeholders.

So, yes, a good database will of course help your CRM strategy. It should do loads of things for you: keep contact information up-to-date, enable you to understand your supporters better, help you communicate with them better, in a more targeted and efficient way, record their correspondence with you, record all their activity with you, mean you can interact with them online and offline and store centrally all such interactions, allow you to allow them to tell you what they want to hear from you…

But don’t let any software vendor tell you that if you buy their database then you will immediately, magically be able to “do better CRM”. It is your organisation and their approach which defines that. The database will help but CRM database software will not automatically implement CRM at your organisation.

Database Options: Packages, Bespoke and Generic CRM (part 2)

If your organisation believes that you have a unique requirement which means you have to develop a bespoke database then this blog post challenges you to consider if this really is the case. In the first part of this post, I detailed my beliefs on the pros and cons of packages vs bespoke systems vs “Hybrid CRM” solutions. And in this second post, I lay out a process which you can use and consider if you do believe you have a unique requirement.

Find out if your requirement is really unique
First of all, you need to find out if what you think is a unique requirement really has not been addressed by other charities using alternative systems or methods. I realise this can be hard to do so here are a few ideas:

• Talk to other charities like yourselves - or even not like yourselves - but who you know went through a similar exercise
• Talk to database suppliers and consultants (email me! I’m happy to help if I can) and ask their opinions. Database suppliers in particular will probably be delighted to speak to you about what they could do to help.
• Look at not-for-profit technology resource web sites for leads and different approaches: itforcharities, TechSoup, LASA's NFP Suppliers Directory, VolResource
• Visit trade shows
• Post questions on web-site forums and email discussion lists
• Ask your employees of their experience at previous charities
• And, of course, search and browse the web

If you find your requirement is partially unique…
If this is not an oxymoron, just how unique is your requirement? Is it just different data you need to record? A handful of additional fields? One extra entity? Partially different functions? A different process?

If you find this is the case then consider the following options:

• Consider using an existing package but with customisation. Consider if a database package can help, even if it means customising/bespoking it and/or if it means almost meeting your requirements (see below).
• Consider using functionality which wasn’t initially made for your requirement – although this does come with a caveat: don’t wander too far from the original aim of the software or future developments in that package may not support you.
• Try changing your processes. Packages are often designed so that they work best with processes which work in a particular way. Ask yourself if your processes are really the only way you could do things, or could you fit them around a package’s approach?So how can you find out if a database package can do this for you? As above, get the package suppliers into your office and ask them – there’s nothing they like better than the thought of a few extra pounds/dollars for doing such work…

In fact, some database packages are pretty good even for bespoke work. Blackbaud’s Raiser’s Edge has its API module, Care from IRIS has offered web services and bespoke/customisation for years, ASI Europe have just announced new web services for their system, and Ciber UK provide Ascent which is good for customisation. And ESIT has taken ThankQ, essentially, historically a fundraising/membership package, and done some great bespoke customisations on functionality on all sorts of areas outside that; very impressive. Even at the lower end of the market (cost-wise) Redbourn have offered additional work on Advantage Fundraiser. Please do note all these are just examples and other database suppliers might also provide similar approaches.

Often, package suppliers are very happy to offer bespoke/customisation work which can form a new module for their system, so although it may start as bespoke work, it will be offered to more charities later and thus become part of their standard system. Quite a common path for many suppliers. Maybe you could even share the development cost with other organisations and/or with the developer? ITSorted and Centrepoint Computer Services are just two examples of companies who have used this approach.

“Hybrid CRM” Solutions
One of the most exciting, new options of recent years for organisations with some unique requirements are to use one of the CRM solutions such as Microsoft CRM, SalesForce, CiviCRM, Pivotal, ODM from Gallery Partnership and so on.

As discussed in the previous post, they are designed to be used across a range of industries. SalesForce’ AppExchange has proven extremely popular and Microsoft now has a similar offering and has approached its future releases with XRM (the idea that you can extend CRM significantly beyond its original goal) as one of its core ideas.

How important is technology?
I do appreciate that one issue for many organisations is that web access can offer so much benefit for integration, roll-out, remote access, home users etc that the technology platform can be extremely important. Unfortunately, some web applications are not as functionally rich as Windows packages. So if you can find a Windows package option but not a web-based solution, but that technology is key for you, then at the end of the day it will come down to business benefits. Would you gain more from having a Windows package and possibly running it across Citrix/Terminal Services, or would a web application with slightly less functionality be better for you?

If it’s really unique after all…
But if you really do find you have a unique requirement, then try asking the following: How much does it really matter? What would the impact be if you couldn’t have such a function? Or only partially have it? Is it a nice-to-have feature or really business critical? Is it for fundraising or service delivery - i.e. who does it affect – you or your clients?

Could you use a package for 80% (90% etc) of your requirements and accept that you can’t do everything perfectly for your final 20%? Does only that final 20% (10% etc) need to be managed elsewhere in other ways? Could the package still help with 50% of your unique requirements (e.g. recording contact information and contact made with those contacts but maybe not a specific issue aside from that) and could you do the other 50% on another system.

At the end of the day…
Of course, at the end of the day it is entirely feasible that you have a unique requirement and will decide that your best approach is to develop a bespoke system, in which case, go for it. But I hope that by considering the package options first you can thus rule them out and have a true business case for your development project.

Database Options: Packages, Bespoke and Generic CRM (part 1)

One thing I am told too often during my database procurement consultancy, is “… we have this unique requirement, so we really need to write our own bespoke database”. To which my response is usually, Really? And what is that unique requirement? And most of the time when we discuss it we find that it is not so unique after all and that an existing database package on the market would be fine - and I would nearly always recommend that you at least consider packages before creating bespoke systems.

Ironically, it is often small to medium size charities who say this and not larger ones with complex structures. This is usually because organisations simply don’t know about a particular package or a specific option available in a package, or it could be that they have not considered how they might be able to use a package's existing functionality differently. The possibility to use existing packages is especially true of contact-centric requirements (e.g. fundraising, membership, client management, volunteers, helpdesk, case management etc). And if the need revolves around “other entities” then there may still be packages available (e.g. collections databases, resource booking).

This blog post attempts to help you consider this issue. I have split it over two posts: the first, below, highlights my thoughts on the pros and cons of using packages vs bespoke systems vs “hybrid CRM” solutions, and the next post will consider in more detail the process you could use if you do believe you have a unique requirement.

Packages
By packages, I am referring to all the pre-written fundraising, membership, volunteer and (in particular) other client/contact-oriented databases which have already been created especially for the not-for-profit sector. As well as some other packages such as collections databases, CPD software, campaign management software etc.

Benefits:

• They are written specifically for charity operations: fundraising, membership, volunteering, charity CRM et al. Simple. Why re-invent the wheel? If there is a solution pre-written, why write your own or “work around problems” of another software package.
• Experience of other fundraisers and charity staff: Such databases are used by other charities and fundraisers which will mean you will benefit from their previous experience and requests for functionality in the package.
• Cost: It is often cheaper than writing your own system. I realise this can be a contentious issue and I provide further references to this below.
• Speed of implementation. A pre-written system does not need to be designed by yourselves and you should be up and running far more quickly than writing your own.
• Support. Most commercial packages offer support hot-lines and with support staff who should understand charities, their operations and their packages.
• Future-proofing. Most commercial packages offer “maintenance contracts” where you can pay a set amount each year and receive enhancements and updates of the package. This can be quite a benefit if a company keeps on top of the latest technology as it will mean you can always have the latest available system.

Potential downsides:

• Cost. Many (although certainly not all) of the fundraising and charity packages do cost thousands of pounds; certainly those with a good range of functions and benefits needed for many serious fundraising operations. Plus support, training and any new hardware required. They can be/seem expensive in terms of actual outlay for smaller organisations.
• Functionality: Can the package really do what you want
• Over-complex: Because packages cater for multiple organisations and requirements, and not specifically for your operations and processes, there may be times when they are (or appear to be) over-complex compared to what you could achieve with a bespoke system. Does the package do far more than you will ever require? But bear in mind this is a common complaint about all packages in many industries, from Word to charity databases.
• Lack of flexibility. How adaptable is it for you to adjust the package to your own requirements? Can you add your own fields or write your own reports? And how easy is it? What about the future when your requirements might change; will the package still be able to meet your needs?
• Companies can go bust or get taken over! It isn’t common but companies can go bust or get taken over by other companies, in which case you could be left with an unsupported system with nowhere to go for enhancements, or “forced” to migrate to a new company’s preferred system.
• Enhancement requests. Just because you ask for an enhancement you will not necessarily get it. Commercial companies often tend to add new functions only where they feel it will be beneficial to more than one specific client (or, if we are sceptical, where they feel it will increase sales…)

Bespoke databases
Writing your own, bespoke database or having one written for you is a popular idea for many small to medium sized charities (and some larger ones too). It can be a good solution for some organisations but unfortunately there are many organisations who do not consider all the implications of doing so. One of the most common misconceptions, for example, is that you can simply buy Microsoft Access for relatively little, and that there will be no more costs. This section tries to give the pros and cons of writing your own database.

Benefits:

• Keeping it Simple. If you are a small charity with simple requirements then it may well be that you really do not need any of the sophisticated requirements offered by commercial charity/fundraising packages. It is not overly difficult to write a fundamental database with name & address information, basic recording of donations, a few simple reports and an export function to a word processor for writing letters. It can and has been done successfully many times.
• Cost. Again, if you do want the simplest of databases and you either have an employee or a volunteer who already knows how to write databases, then the cost can be kept down. Although bear in mind all the costs of development.
• Designed for your requirements. There may be cases where you have to have something written for you because you have specific requirements which a commercial package cannot match.
• It’s not just for fundraising. For ‘organisation-wide’ (or "corporate wide") databases where you might want to hold information other than just fundraising all on the same database, then you could consider a database written especially for you. For example, if you also wanted to record the public’s requests for information, client details, detailed child sponsorship (or similar) schemes, internal data, cause-related information, research and so on. But if this is the case, then a database of this size will cost a lot to develop and there may well be packages which will do much of what you want and/or the suppliers are happy to make bespoke changes for you.
• It is yours to change. If you do get someone to write a system for you then you will also probably have access to the database structure and “source code”. This means that if there is someone in your organisation who knows how to program this database then they can change it as and when you want it changed. And potentially far quicker than with a commercial package where they need to consider the affect of any change on all their customers.

Possible downsides:

• They are not pre-defined. As stated above, it is a common misconception that you can simply buy a database package such as Access, Filemaker and so on, and that is all there is to it. All these packages are simply tools which let you write your own system, and you need to add everything to it: fields, lists, screens, specific functions, reports and so on.
• Design. You have to design your entire system. This means thinking about all the data which you want - or might want - to hold. It means meetings with users, planning, writing a specification, designing fields/screens/functions/reports and checking to see if you have thought of everything. If you are getting a company to write a system for you, then if you forget anything at this early stage then they are highly likely to charge you more later if you want to add/change anything.
• Cost. Again, although it can appear to be cheaper than buying a pre-defined package, there are many cost considerations. For a start, if you are considering getting a commercial company or independent developer to write a system for you then this really can be expensive. They may well charge for feasibility & design as well as programming, and no programmer worth their salt will be less than several hundred pounds a day; and it will take many days of their time. Even if you are writing the database ‘in-house’ (i.e. having your IT staff write it) then all the above issues can add up.
• Time. Writing your own database can take a long time and one of the sad facts about the computer industry is that projects always seem to take far longer than expected!
• Support. Who will give you support after the package has been written? What about help screens? Or a user manual?
• No future-proofing. This in itself can outweigh many of the advantages of writing your own database. Inevitably, some time after you have written it, technology and your requirements will change and you may be left with an out-of-date database. If you want it changed or updated then back come those costs all over again.
• Database querying/reporting. One specific issue of writing your own database but where you want other people to be using it, involves querying the database. This is one of the most common complaints of any user, not just in charities - that their database can record data okay, but it is very complex to get the data out.

“Hybrid CRM” databases
The last few years have seen CRM systems which were originally commercially oriented now adapted for charities’ use, some very successfully (e.g. Microsoft CRM, SalesForce), and other CRM systems of the same ilk but specifically oriented at the nonprofit sector (e.g. CiviCRM). These offer some different pros and cons to both the above options, and some similar issues:

Benefits:

• You may get the best of both worlds: a package where the heart of it has fundamental contact management and associated functions such as querying, reporting etc, and which is thus upgraded with new versions over the years, but which also offers you the ability to add bespoke or customised areas for your charity-oriented requirements.
• Some such systems now have “templated” charity options. Some commercial companies have taken these ‘vanilla’ CRM systems and added charity functions such as Gift Aid, membership etc. So you get a head start on your specific needs.
• The software licenses themselves tend to be quite cheap or even free for open source. Just the software license, mind, i.e. the licenses which simply allows you to install and use it. The true cost of these systems is in the designing, development and implementation and/or in purchasing a ‘templated’ version.
• Flexibility of using different support companies. Most such CRM systems are sold through re-sellers, so that even if you purchase and start with one such company, if you fall out with them or they go bust, there should be many others which can still support you. Quite a benefit.
• Often good for organisation-wide databases. If you have requirements which stretch past ‘just fundraising’ or ‘just volunteers’ etc, and/or your requirements in those areas are not overly-sophisticated, then these CRM systems can be very appropriate as they will offer good, general functionality and you may not have to customise the database too much.
• A far wider customer base than any charity supplier. The more popular CRM systems will have thousands, tens of thousands of organisations using their systems (not all not-for-profit, of course). Even the largest charity suppliers will struggle to maintain such numbers. In theory, therefore, you will have a better chance of longevity, support, a robust system etc. It also means a wider user community who can help you, who may develop specific requirements, arrange user group meetings etc.

Possible downsides:

• Non-charity functionality. Like bespoke systems, it is likely you will still need to develop specific functionality for many of your standard charity-oriented requirements. This can be extremely time-consuming and costly, depending on the needs, and/or not at all easy.
• Higher risk. For the above reason, it can be a higher risk strategy to attempt to implement such systems than traditional packages. Perhaps not so much for smaller organisations or those with simpler requirements, but to replicate fundraising/membership functionality from packages will be a longer, riskier project.
• Templated versions are just a starting point. Even the templated versions of such systems are still just starting points. You may still need to develop them further for your needs, which will cost and take time, and they may cost more in the first place to pay for the specific supplier’s initial outlay in developing such functionality.
• Cost: Considering the above three points, costs can really start to add up. Yes, the licenses may be cheap/free but developing and customising can be expensive, especially if you need more sophisticated functionality. Go in with your eyes open.
• Suppliers (re-sellers) may not have such good charity/fundraising knowledge as charity package suppliers. This can be key to a good development of these CRM systems. If the supplier doesn’t know your market so well, then even if they perform a good “needs analysis” phase with you, they may still miss issues or good options because they haven’t got the previous experience, and if your users don’t ask for such specifics, then you may not get such a streamlined solution as you could get from package suppliers.
• Re-inventing the wheel. Again, why do it if your requirements are specific to your sector or simple?
• Fewer charity users. Although there is no doubt that some of these systems really are growing in charity usage, the larger and more popular charity-specific packages will currently still have more nonprofit organisations using their databases.
• More functionality than you need. Like packages, they may provide much more than you need in some areas, which might make them more complex than you would want.

In my next post, I will consider in more detail the process you could use if you do believe you have a unique requirement.

The 3 Most Important Things To Do in a Data Migration Project

Most times when you implement a new database, you will need to migrate the data from an existing database (or databases, or spreadsheets…) to your new system. And assuming you don’t have just a few hundred records – in which case, it might be far more pragmatic to re-key them into your new database – you will need to perform a data migration exercise. Below are what I consider the three most important things to do in a data migration project:

• Create a Mapping document. You need to define exactly where in your new database all the fields in your old database will be mapped to. Put it in writing. Review it, clarify it, validate it. You might also define specific rules so that data from certain old fields could get mapped to different new fields depending on the value in the old field, or certain records do/don’t get migrated at all depending on a particular code/field value.
• Test Test Test. The minimum number of ‘trial iterations’ you should do is two, and for more complicated data migrations you may require more. After each iteration, test. Test record counts, financial totals, eye-ball records for field level matching, do performance testing, stress testing, test business processes, security, do regression testing. And so on and so on. Test test test.
• Make sure you don’t treat a new database implementation purely as a data migration project - and don't do a data migration project without remembering why you are implementing the new database in the first place. It is easy to do, to get so involved with the granular level of data that you lose sight of why you are implementing a new database in the first place. Remember the project benefits. Of course the data migration is a key element in a database implementation, and it can make-or-break at least the initial phase of such an implementation, but it’s not the be-all-and-end-all.

There is of course far, far more to the actual database implementation and many factors from that will feed into the data migration exercise (e.g. workshops, database design, change management and so on). So the caveat to the above is that this is written purely from the specific angle of the data migraiton itself.

Thus, whereas the first two points above are the most important in terms of the specific exercise of data migration, there is no doubt that the final point is the more important for you as an organisation and for your business needs.

KISS Contacts Software Review: A fundraising database for £100

Can you get a decent fundraising database system for a small charity for just £100? Well, if you buy KISS Contacts then by and large the answer is “Yes”. It isn’t as rich in functionality as your Raiser’s Edges, ThankQs and IRIS’s, it may not be the most beautiful system, and it’s unlikely that it is the most appropriate system for more than a few simultaneous users or tens of thousands of records, but that is not its market. It’s primarily appropriate for small charities and membership organisations who need a quick, simple dedicated fundraising/membership database and for that sector it offers a good deal.

The first thing you’ll want to see is the main contact screen, and although it’s quite busy and small (KISS is written in Access 2000, but that does mean it will run and look fine on older PCs), you can record lots of information. All your standard contact details, income, contact history (I like the fact you can see phone calls, emails etc and donations on one screen), links to other contacts, mailing preferences, notes and even a certain number of user-defined fields.

In terms of income, you can of course record your standard donations and allocate them to funds and state a source of the donation, but you can also manage standing orders and even direct debits; that’s pretty impressive for such a cheap system. And you can record Gift Aid Declarations and manage Gift Aid claims.

If you’re a membership organisation, then you can manage your membership in KISS. You can define membership types, produce renewal and ‘chaser’ mailings and show late payers. And the memberships can be linked to the payment method. You can only have one membership per contact, but for most small organisations that is probably not going to be an issue.

But no system is worth much unless you can get data out and KISS can do that too: mailings, labels, reports and data export. It is a bit limited in terms of the record selection functionality but it can still do comparatively simple selections. It has a series of useful, pre-defined reports and you can also export the raw data so you can do further analysis outside the database if you wanted to (i.e. in Excel etc). And because it uses Microsoft Access, you could write your own reports in your own copy of Access, Crystal Reports etc by linking to KISS’s back-end database.

It even has a built-in Help system and a limited audit to show historic changes to some of the key fields on the system.

What doesn’t it have? There is only one login name so you don’t have different levels of security (although I understand this is planned for a future release); you can email multiple contacts at one time but you can only do this directly from KISS by using Outlook’s blind copy (“BCC”) method (although you could export email addresses and use dedicated mass email marketing software); the record selection/query system is not as sophisticated as you would get with more expensive databases and you can’t do ‘ad-hoc’ queries on any field; there is no event management functionality (although, again, this is planned for the future); and because it uses Microsoft Access, you can’t run it across multiple sites/locations unless you use something like Terminal Services (but plenty of much more expensive fundraising packages have the same issue). And, as I stated before, the screen design is showing its age, with fields tucked tightly into forms and not using the whole potential of larger screens. I understand from KIS that they are planning to move the software to Access 2007, so this may help the look-and-feel.

But all of those issues are comparatively tough criticisms on such a cheap system and for most small charities, they probably wouldn’t matter too much.

I think, because KISS uses Access 2000, there could also be the potential for some conflicts if you are also running other versions of Access on the same PC. This may be a good reason to use KISS’s runtime version of Access 2000 which comes with the product. Again, the potential move to Access 2007 should help this.

As an organisation, KIS Software Solutions can only offer support via email and online support forums, although there is of course the built-in help system too. KIS feel that for many installations, charities should not need training, or rather you can self-learn the system, and I probably concur as long as you have some experience of using a database or you are data savvy. But they do organise training for clients who want it, or those who want advice on setting up the system, especially where the database is networked.

The system is also limited in structure and screen design to pretty much what you see (with a few neat tweaks here and there). But actually, because there is only so much you can do with it, it won’t require a steep learning curve, costly configuration or an expensive implementation and that certainly is a benefit for small charities.

In terms of alternatives, I would expect it to mostly compete with a few other similar, low-price databases or where a charity is considering writing its own database in Access or Filemaker etc. For the latter, KISS wins hands-down; why spend months and money on re-inventing the wheel when KISS does so much of what you would want from a fundraising database already?

Some charities might also consider the more recent adoption of web-based solutions such as SalesForce, Microsoft CRM, CiviCRM et al, and those solutions do offer more flexibility, customisability, a better look-and-feel and a web interface; but if it is mainly fundraising or membership functionality you are after then you would certainly spend plenty of time configuring the above systems to achieve some of the specific functionality you get in KISS.

If you are a small charity or membership organisation and you need a simple, solid fundraising/membership database to support your operations, then KISS should certainly be on your radar. For £100 it is truly excellent value.

For details on how to contact KIS, visit KIS Software Solutions' web site.

Top 10 Benefits of Project Management

I have been fortunate to have been a project manager at several leading charities over the last few years, mostly on database and CRM implementations, but also on other IT and finance projects. Here is my list of the key benefits I believe a good project manager should bring to any similar project:

• The project team and staff will know what is going on and what is expected of them. This is possibly the most important aspect of any PM’s role – without this, there is a high potential for lack of leadership and the project failing.
• The bottom line: a project manager must monitor, maintain and know the overall and current state of the project budget, timescale, resources required and deliverables and produce the associated reporting to the project board. This is clearly a key aspect for any PM.
• Maintaining an up-to-date project plan, including milestones. (NB: It is usually not sufficient to solely use a project plan provided by a software supplier as inevitably that does not incorporate all the internal needs and issues which the client has).
• Keep the project board up-to-date with monthly meetings and (usually) more regular highlight reports. A good PM can also work with the project board when it comes to discussing and making decisions on the project when it is not going as well as it should be.
• Co-ordination and centralisation. With a large project, it is imperative that everything is fed through a central resource and everyone knows how to do this.
• Monitoring resource allocation: Whilst the PM is not responsible for the actual resource allocation, it is important that they monitor how resources are being allocated and ensure that necessary resources have been planned for.
• Communication: not just with the project board and the immediate project team, but with the users and potentially a wider audience to keep all interested stakeholders up-to-date.
• Task dependencies: A key aspect of a project is that many tasks are dependent on other earlier tasks or must be started/completed before other tasks can happen. Again, this is something which needs to be monitored and understood.
• Risk assessment and issues management. This is a critical requirement and incorporates maintaining a risk register and issues log; and if it doesn’t go quite as far as being a ‘trouble-shooter’ then it certainly involves identifying and understanding the risks when trouble might appear.
• Prevent (un-authorised) scope creep.
• Supplier liaison/management and co-ordination

Okay, if you counted, then you will see there are 11 benefits – sorry, I just had to sneak them all in!

Is £0 Really Too Much to Pay for Gift Aid Software?

A report today on Third Sector’s web site states that, from a survey of 896 charities, “more than four in 10 charities do not maximise their Gift Aid claims,” and that “the main reason cited by respondents for not using online systems was that they lacked IT capability. Only 15 per cent of respondents said they would be willing to pay more than £50 for software, and 42 per cent said they would not be willing to pay anything at all, including 15 charities with incomes of more than £25m a year.”

I can’t believe this! Can that really be the case that so many charities don’t see the benefit of spending any money at all on software to help them make Gift Aid claims? It beggars belief. To the extent that I actually wonder how the relevant question(s) were phrased in the survey. Is it that those charities who responded in this way already have a fundraising database and therefore don’t want to spend more money on specific Gift Aid software? If so, then I can understand that, as I would hope that most fundraising databases should be able to manage Gift Aid perfectly adequately, at least at a basic level, even if they can’t all manage all the complex nuances of specific, more difficult Gift Aid rules. (And I have to believe that this is the case for those 15 charities with income over £25m a year – they can’t be running Gift Aid on paper based systems…)

I do realise that some Gift Aid issues are more complex than Gift Aid on 'straight forward' donations, and so those respondents who “supported the simplification of current rules [for] auctions, entrance to attractions, sponsored events and donations through self-assessment tax returns” probably have a fair case; such claims can be more difficult to administrate and automate in software packages - although not impossible. But in terms of ‘standard’ donations, it is interesting that Barry Gower, Gift Aid expert at GAIN, recently stated at the IoF National Conference that he feels the current Gift Aid system “is not broken”.

Either way, we have what we have at the moment, so that is no reason not to spend at least some money on ensuring you maximise your Gift Aid revenue. In fact, I wonder if it is a charity's moral duty?

So I just wonder why these charities refuse to spend any income on software to help them with their Gift Aid (assuming that really is the case)? Do they not understand the benefits? The time and effort they will save, the ability to automate R68 reports, the increased accuracy and automation of income processing and claims, the potential to go back over previous years and back-claim gift aid from a donor’s earlier donations? The speed to find Gift Aid Declarations? The increased ease to monitor and manage oral declarations? The power of reporting on all this and the ability to analyse and improve your marketing and income processing? And as a result of all the above and more, the extra income they can potentially make from using Gift Aid software to efficiently and pro-actively administrate their Gift Aid?
Or do they think the software is too complicated to use? That the administration to run such software systems is so high that it outweighs any extra income? Surely not. And do they not know there is dedicated Gift Aid Management Software for small organisations which costs from just £30?

So, please, if you work for one of the charities who responded to this survey and who said they weren’t willing to spend anything at all, then let me know why in the Comments sections below. Have I mis-understood your needs or message? Or has the report misconstrued your answers? Because you have to trust me here – one of the best investments you will ever make in software for your charity is on software which will help you do Gift Aid claims. It is one area we can really show an almost guaranteed ROI! The largest charities can claim thousands and thousands of pounds as a result and even the smallest charity who does pro-active fundraising will surely benefit from either a decent fundraising database which supports gift aid processing or the simplest of Gift Aid software packages.

Because, if it really is the case that such charities are not using any software at all to manage their Gift Aid then that worries and depresses me. Please tell me I’m wrong. And you won’t hear that very often from a consultant!

16 Ways to Improve User Buy-in

Many database implementations are planned and considered with some input from the end-users, but if the project is a long implementation or there are many end-users who thus may not be involved day-to-day, then there is a risk that such individuals may become disillusioned or disenfranchised from the project.

Here’s a few bullet points (in no particular order) to help encourage user buy-in to a project:

• Continual communication: probably the simplest and quickest but unfortunately the most under-utilised. It doesn’t need to be much, e.g. a regular email to the end-users and/or through their managers, updates on your intranet, brief presentation at team meetings etc, they all help. And you can get feedback from the users too. In addition, many of the points below by their very inference are continual communication, but having a structured approach can really help.

• Involvement at design stage: Do involve key users at the time you are designing the database, whether it is the customisation of a package or the detailed design of a bespoke system. This may sound obvious (even necessary! I hope so) but it works. And do plan ahead for any such involvement; I find users really enjoy and want to get involved but not if you ask them to do 2 four hour workshops next week when they are just about to launch a new campaign!

• Demos of the software & opportunities for hands-on experiences during the implementation: Show the software to the users – it’s a great way to get them excited about the new database and even if you do an initial demo at an early stage, then you can ask for their feedback and comments and make them feel even more involved.

• Assurance of training: It’s always one of the top 3 questions from users – What sort of training will we have? So give them details as soon as you know, and even before that, pre-empt the questions by assuring users that training will be provided.

• Ask for ideas – during implementation and after go-live: Continue to ask the users what they would really like, although you’ll need to this in a ‘controlled environment’. If you let them ask for anything and expect everything then that can be worse than not asking at all, so do communicate that ideas will be considered but may not all be implemented.

• Keeping promises, so don’t over-promise! Hand-in-hand with the above, and in general, keep your promises but don’t over-promise. A slightly trite phrase is ‘Under promise and over deliver’ and even if I don’t like that specific thought process, the underlying concept is reasonable.

• Remember, What are the benefits to them? When you’re selling a new database to the users, what are the benefits that they are going to get themselves? It should of course be the case that the organisation will benefit from a new database, and although that should ultimately mean the users will too, it can also mean that processes may change, more data entry may be needed etc. So, identify specific benefits which the users will get and communicate those. That will help them understand the need for any changes which they don’t like so much.

• Pro-actively address the common objection of “I don’t know what I want from the database because I don’t know what a database can do” – because it’s (usually) a fair point. Don’t just ask, ‘What do you want the database to do?’ because many users quite simply will not know the capabilities of a database. If they have not had experience of a really good system then they may not be aware of all the benefits they can get from one. Instead, ask ‘What do you do in your job?’, ‘What are the problems you have?’, ‘What would make your life easier?’ and so on. Classic business analysis.

• Stories of how other charities have benefited from it: Find out how other charities have benefited from the same database as you are implementing and tell your users.

• Quick wins: It’s a slightly hackneyed expression, but can be very useful. If there are Quick Wins which you can implement when you do go-live then try to do those. It will show how the new database can help and keep up enthusiasm.

• Listen! And acknowledge.

• Automation: In pure technical terms, automating a process is one of the best benefits many users can have. For example, instead of having to enter a donation, then open Word, cut-and-paste an address, write the letter, insert the donation amount etc - automate it. Yes that is basic but even basic automation helps. And if you can automate even more complicated tasks then that’s even better.

• Excite the users by implementing one or two really ‘whizzy’ things! E.g. Maps with donor details plotted on them, analytical graphs they haven’t seen before, automation and interaction with the web. It’s going to vary between organisations as to just what is considered whizzy, but by doing just a few high-tech things early on after go-live, it does get people excited.

• Involvement at Testing. Again, I would hope this is a given, but do involve your users at the time of testing. It isn’t the most exciting of tasks but it encourages adoption and involvement.

• Competitions: I have known charities who have run competitions during their implementations. For example, every week/month during the implementation phase, they send out an email with a question which relates to the project and to which the users will know the answer if they have got involved, if they check the intranet for updates etc. The charity then does a random draw and the winner gets a prize. A very small prize to start with but as they progress through the project, so the questions get more involved (e.g. when training users, ask specific questions about functionality) and one charity even finished their competition by giving the lucky winner an extra day’s leave.

• Be realistic about implementing new changes. Having said all the above, be aware that implementing a new database is a time-consuming experience. Don’t expect to implement lots of new things on day one of go-live. Make sure you get the basics right and plan any key changes carefully. Users will thank you for that.

Anyone else got any suggestions?

The Raiser's Edge: Why does one person like it and the next hate it?

I have recently been talking to several charities who use The Raiser's Edge. And it seems to me that whenever you gather together a group of fundraisers, throw in a few charity DBAs (and a pinch of technology consultants), and start talking about The Raiser's Edge, then, almost inevitably, some of the group will sing its praises and others will slate it and tell you it’s rubbish. But why? It’s the same software being used at the different charities (possible version differences aside), with the same functionality (modules aside) and surely all organisations could use it the same way? So why then, if one person loves it, does the next person find it just doesn’t work for their charity.

At this point, I should offer a clarification and a caveat on this blog post: To clarify, I have used The Raiser’s Edge in the title of this blog because it is used so widely in the sector and thus you inevitably get more people discussing it and therefore liking and disliking it. It is one of the more long-standing products on the market and fundraisers have inevitably heard of it. However, most of the points in this article could equally apply to any other similar fundraising, membership or CRM database package.

Secondly, the caveat is that such a question cannot be answered truly comprehensively in a brief blog post. Each of the points below could justify their own post (or set of posts!) and far more discussion. And of course there can be specific reasons why a database does not work for a specific charity. But because I am asked this or similar questions regularly, and because I really want to encourage charities to consider and understand the fundamental issues so they don’t immediately blame Blackbaud or similar suppliers, I hope this initial post will provide a fair and useful overview and supply the start of the answer.

So here are a few suggestions as to why we love to love or have to hate The Raiser's Edge:

• Data. I have been fortunate to have done quite a few data audits of Raiser’s Edge installations and the data in the system is one of the most important factors in the success of its implementation. Data Quality (accuracy, integrity, consistency, use of look-up tables etc) is key, the data needs to be up-to-date (a classic hate for fundraisers), the breadth of data (or lack of it) within constituent records affects data quality, as does the relevance of data and the trust which fundraisers put in the data which is stored on the database – all these are vital components. Too often I hear words along the lines, “we don’t believe the data in the database is correct or up-to-date”. The time which Raiser’s Edge has been used at an organisation is another factor in this - the data may well have been excellent when it was first implemented but over the years it has deteriorated. That happens, and often it is the poor database which is blamed. Data is the foundation of all good databases and if there are problems with the data then it doesn’t matter how good or bad the database software is.

• Set-up and configuration for your charity – during initial implementation and thereafter. The Raiser's Edge is a sophisticated but quite complex database to learn, even more so to use optimally. And how you use it, how it is configured, where you store data, how you use the “cornerstone” codes and so on can seriously affect how good the implementation is. Codes such as Constituent Codes, Fund and Appeal codes, Action Types (horribly abused in some systems I’ve seen) attributes and so on all need careful attention. And continual attention – if such tables grow uncontrollably they can become unwieldy and unusable. And where you store specific data items - attributes or ‘cons codes’, Appeals tab or Actions, etc – can fundamentally affect the usability.

•  Your Raiser’s Edge Database Manager. For a starter, you need one. Don’t try without. And a good RE database manager is worth their weight in gold: a good database manager not only understands the software, how to use it, what it can do and so on, but can also understand or learn your business, operations and needs and can apply all that information to the implementation so that it bring huge benefits to your charity. I don’t believe that Raiser’s Edge database managers need to be extraordinarily technical people (although a solid technical understanding is very useful) - far more important to me is that they can apply your fundraising requirements to your fundraising software. Give me a business expert with some database knowledge who can learn the system over a ‘pure’ RE database manager.

• Training, procedures, user guides. Again, it doesn’t matter how good or bad your software is, if your users aren’t trained then how can they be expected to use the database to its best potential? And ideally, good procedures and user guides to back-up the training are a key element to the success of the database. (Anyone actually have a data dictionary..?) And please keep them up-to-date…

• Hardware and IT infrastructure. Probably one of the most common complaints I hear about The Raiser's Edge, or any database is, “It’s so slow…” Now of course this could be how the database has been designed by the software supplier, but if one implementation runs fine and the next does not, even with similar record numbers, then that is less likely. Just as likely (more likely?) is that your server or PCs are not of the recommended specification, your network performance needs investigation/optimisation or the IT infrastructure for your remote offices is not sufficient for the database.

• Applicability to your organisation. This is one area where it is feasible that The Raiser's Edge may not be the right database for you. If you are a small organisation with few records or a huge organisation with many millions of records, then The Raiser's Edge may not always be the most applicable. Blackbaud, understandably, will show that RE can help small organisations and that even RE7 can manage millions of records (although their next generation Infinity platform will be better for that), but it is feasible that other solutions could be more applicable. This is of course one point which is completely organisation-specific. It can also be the case that over the years your requirements have changed so that The Raiser's Edge may not meet your current requirements whereas it did originally.

• Blackbaud-specific likes: The Raiser's Edge is generally good quality software, it has good querying tools, and is especially useful for non-technical users; and Blackbaud offer great longevity as a company and have produced many upgrades over the years and with exciting propositions for the future. Users like the software and the company for that. It has many charities using it so you get a good user community.

• Blackbaud-specific hates: Hmm, this really can be a favourite topic for some fundraisers and database managers! (And I’ve certainly had my own gripes over the years…)  As mentioned above, The Raiser's Edge is sophisticated but complex software (in fact, “The Raiser's Edge is so complex…” is probably the number one ‘complaint’ I hear about it) and it does need time and dedication. So if you don’t have people who can put in the time, or that is not your organisation’s requirement then it can be understandable why people don’t like it. RE7 can be quite prescriptive and in some ways it is less flexible than other companies’ offerings in terms of screen layouts, customised fields etc (unless one uses their VBA/API tools), and I personally believe that for the first time recently, RE7 is starting to show its age in that way compared to newer alternatives on the market. Equally, Blackbaud themselves are a large company and not everyone’s cup of tea, support has been up-and-down over the years (it has many clients and some users complain of feeling a small fish in a big pond) and users do relate to previous bad experiences. And it is not cheap. It certainly isn’t the most expensive solution on the market but there are very good, less costly alternatives for small organisations.

So if you are using The Raiser's Edge and you are finding it is not doing what you want it to do, then do consider the above points before you look for an alternative.