Showing posts with label Volunteer Developed Dbs. Show all posts
Showing posts with label Volunteer Developed Dbs. Show all posts

Monday, November 05, 2012

Do Generic CRM systems make "Volunteer Developed" databases a viable option now?

Volunteer Corral Building 
Historically, I have never promoted volunteer developed fundraising databases (as much as I respect the time, effort and great intentions of such volunteers). i.e. taking MS Access, SQL Server et al and creating a fundraising system from scratch. But with the recent availability and flexibility of the generic CRM systems (MS CRM, Salesforce, CiviCRM et al), I am wondering if there is now a new 'volunteer developed' model which smaller charities can instigate.

My concerns historically about volunteer-developed databases are based on fundamental issues with such an approach. For example: volunteers may not understand fundraising or fundraisers' needs and thus not design systems in the most appropriate way; volunteers may not be around tomorrow to maintain, change and improve their databases; volunteers may not provide on-going support or training; the system will probably be a bespoke development and will therefore only provide what the charity wanted at that time; and the underlying database may need to be upgraded but without anyone to do it.

And equally important, such approaches are almost always re-inventing the wheel. Traditional fundraising packages have been available for 20+ years, and even if some are expensive, with fundraising packages such as KISS Software costing from only £100, why would you consider bespoke development for small charities' fundamental fundraising needs. Indeed, I know many NFPs who have started with volunteer-developed databases but have found such systems stopped being useful, even to the extent that they found they stopped using them any more in their organisation.

However, as per my introduction above, with the 'new' generic CRM systems, this may be something we can now review.

The reason for this is because of the cost structure of these systems and the central core of their data models. Cost-wise, the software prices of CRM systems such as these are very low indeed; e.g. CiviCRM is open-source, Salesforce offer NFPs 10 licenses for free, Microsoft offer heavily discounted pricing for charities. And thus the majority of the costs are in the database implementation. And if a volunteer can therefore configure such systems for a charity's needs (hence avoiding/reducing some costs) then some of my previous concerns about volunteer-developed systems may be negated completely or to a large degree. i.e.:
  • These CRM systems have a standard structure which means that fundamental contact management requirements are already there, and thus reporting and mailing functionality is taken care of.
  • These CRM suppliers will (for the foreseeable future) certainly be providing upgrades, bug fixes, improvements to central functionality/technology platforms and so on.
  • Even if the volunteer stops volunteering for your charity, the wide adoption of these CRM systems - within and outside the NFP sector - and their standard approach, should mean you can find someone else to help and support you. And there are many online discussion boards which can supplement such support too.
I should add that there are caveats to this approach: it is probably still best suited to small charities with low budgets; I would ideally want such volunteers to be "configuring" the systems as much as possible as opposed to "customisation" (i.e. no heavy coding - instead use the system's in-built tools and third-party apps as much as possible - "keep it as vanilla as possible"); and get them to document whatever they do for you.

And it still doesn't fully negate the need for them to understand your fundamental fundraising needs. Some of these systems will have some fundraising functionality but it won't be the same as buying a traditional fundraising database or even paying for one of the ever-increasing "fundraising templates" you can now get for these CRM systems.

And this approach is, still, to a degree re-inventing the wheel. But only to a degree. And certainly nothing like developing an Access or SQL Server database from scratch.

So, as much as I realise I may be setting myself up here, I think that now, for the first time for some time, for smaller charities with low budgets, using a volunteer for such database developments may again be a viable option.

Wednesday, June 23, 2010

Why Free Software Doesn’t Mean Zero Cost

Listen to MP3 version
I love the concept of open source and free software, I really do. But I get equally frustrated and concerned that some organisations believe that free software equates to spending no money at all on a database implementation. There are many other costs to consider, explicit and hidden or mis-understood, and charities need to recognise these and go in with their eyes open if they choose to use free software in any of its guises. Here are just a few you should consider:

  • Development costs. Even if you use open source database software such as MySQL, "existing" software you already own such as Microsoft Access (and which therefore has an implied free price tag), a free web-based system such as Zoho, or even the free NFP version of SalesForce, then you are still going to need the database to be developed or customised for your needs. And for some of the above it is highly likely you won't have the skills in-house and you will therefore need to recruit/pay for an external developer. You may find a volunteer which would of course mean a zero price tag for their actual work, but volunteer-developed systems carry their own risks and other potential costs (c.f. below). And even if you do have internal staff who can develop the database then you should really factor in their time and, therefore, costs into the equation.
  • Training and consultancy. The software may be free but companies and consultants who provide free and open source software, understandably, need to make their income somehow, and training and consultancy during your implementation may not be free.
  • Data migration and data cleaning. If you have an existing database/spreadsheet then you will need to transfer that data into your new system. As per above, companies may well charge you for such a service - although if you only have a few hundred records (or even a few thousand), then it might well be more cost-effective to re-key it (although even that has its associated costs...) And if you haven't used a structured database before (and even if you have), then you may need to look at your data quality. It's a hackneyed but true statement that just because you get a great, new database, it does not mean that any rubbish data will suddenly become clean and effective. Data cleaning, whether manual or electronic, has costs.
  • On-going Development and Maintenance. It is almost definite that you will need some further development and changes made to the initial database you implement. Whether this is because your requirements change, or future opportunities arise, or bug fixes are needed; or the actual database software you are using will need upgrading, whether it is the "underlying database" (such as MySQL, Access etc) or the actual application itself when new versions come out. Remember new versions may be optional initially but they could become far more important or imperative if other aspects of your IT infrastructure change. I have worked with more than one charity who has been unable to upgrade some of their overall IT infrastructure or software because their free, central database does not support the latest versions of MS Office, browsers etc, and this has caused immense frustration internally. One of the great benefits of commercial fundraising and membership packages is that they (should) have new versions released with new features and supporting new platforms, and if you have a good maintenance/support agreement with such companies then these can even be included in any on-going support costs.
  • Support. How are you going to get on-going support, even whilst you aren't developing the software? Will your free supplier always be there, will an individual always be around to help as quickly as you need them to? Will their skills deteriorate? And even if the database software is free, if you have internal IT staff then they will still need to support the database in some way, whether explicitly in its development or just in terms of on-going, every-day running, back-ups and so on.
  • Hardware and IT infrastructure. Depending on the database you implement, it may need its own server and you may need to consider the configuration on your PCs/clients, such as operating systems and RAM. And you might find other software applications you are already using are not compatible (or not "recommended") so you might need to upgrade them.
  • Hosting and communication costs. Alternatively, if you are planning to host your database elsewhere, then it is highly likely you will have costs associated with that.
  • Bugs. Not so much in open source software, which has great communities to support it, but in free, proprietary software, there may well be more bugs than you would find in commercial software. Of course this may not be the case, but if it is then there is going to be less incentive on the supplier to provide bug fixes. And, depending on the bug, it can be extremely frustrating if there are specific functions which don’t work for you and thus you need to find work-arounds which can take time and effort. (Of course, believe it or not, commercial software can have the odd bug too...)
  • Volunteer-Developed databases. Just a few words on this very specific point: I have worked with various charities who have had a volunteer (very kindly) develop a database for them and in some instances that possibly was the best option at the time. And some of those systems have been really good. But volunteers do not have any accountability, no time commitments to your organisation, possibly less experience of your particular market and requirements, and, as it will almost definitely be a bespoke development for you, then there is no guarantee they can continue to support or improve it. I know many NFPs who have started that way but found such systems stopped being useful, even to the extent that they found they stopped using them any more in their organisation. With so many low-cost and free (yes, even the free ones) fundraising and membership packages and web-based options around these days, I would always encourage you to consider them first before you embark on a volunteer-developed system. If you have a truly bespoke and specific requirement and you have a suitable volunteer then it is an option, but go in with your eyes open.

Free can be great. Open Source can be a wonderful thing. But do consider all the costs, benefits and downsides of such systems versus a commercial alternative. And if it is still right for you then fantastic - go use!