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.