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.