Learning From How a Toyota Supplier Saved $1 million by Updating Its Tech Infrastructure

 

My second post in an on-going series of blogs on lessons we can learn from commercial sector technology implementations.

---

A recent article on TechRepublic shows how Toyota supplier, AW North Carolina (AWNC) spent $1.2m on new Cisco equipment, which has led to significant savings for them. Few charities will invest that amount in a new CRM system, but some of the approach which AWNC took provides us with very useful ideas for the benefits which charities may get from new CRM implementations, often regardless of size.


1) "Downtime at AWNC costs $272,000 an hour, so it's crucial to get systems up and running as quickly as possible. Any downtime, particularly in shipping, is incredibly detrimental."

Okay, so it's unlikely that a CRM system being down for an hour at a charity would have quite such high costs! However, downtime due to a poor or unsupported system or inadequate IT infrastructure is not always factored in to a charity's view on whether they need a new CRM/fundraising system.

So consider: what would it mean to your staff if they couldn't access their database for an hour? Probably, it wouldn't be terrible for most fundraisers/staff, they could cope for that time, although Supporter Services would no doubt find it awkward for managing in-coming phone calls. But what about half a day? Now staff will be getting more anxious, a backlog of income processing might build up, supporter services are finding it more difficult and major donor fundraisers can't see their contacts' details. What about a full day? Much harder now: thank you letters might be delayed, management for a forthcoming event becomes much harder, and what would happen if that day happened to be the day when you were due to do your Direct Debit claim?

So it's not just the cost of a new CRM system - all this needs to be considered when looking at investment.

2) "As a result of the new technology, AWNC avoided maintenance costs on the old equipment of $1 million in the first nine months the system was in place"

Again, unlikely for most charities that they will save $1m in nine months due to replacing a CRM/fundraising system, but I have come across several NFPs who are paying existing suppliers ridiculously high annual maintenance costs for what they are getting, even without upgrades and developments. And/or they have to have specialist, higher paid staff for their current, old system because there are so few people who can support it. So even if it is going to cost you £x to invest in a new CRM system, what are your savings going to be in the first 12 months? (In the next 5 years?) Forget "possible extra income" benefits for a moment, these figures are hard cost savings.

3) "About 40% of the savings will be ongoing and realized annually."

We forget this sometimes, that savings (and benefits of course) will not just be the first year, but over the following five to seven years. So in addition to point (2) above on immediate savings, what other costs will be lowered or made more efficient by a new system? Lower staff costs? Or maybe, the same staff costs but those staff being far more efficient, productive and proactive? Time-savings from quicker processes? Time-savings (and better productivity) from simpler, quicker development tools? Development you can do in-house now rather than having to always go to an expensive software supplier?

4) "It was very clear... that the infrastructure was not keeping current with where the world had gone."

We're all aware that digital is where fundraising is going. Yes, there will still be plenty of 'traditional' or offline income coming in for some years to come, but that appears to be declining, and GDPR/DP issues could be forcing our hand in terms of reducing direct marketing. There is a point when you do need to review how and whether your existing CRM/fundraising system can support you and provide additional benefits with your future fundraising plans because of changes in the outside world.

5) "It's common in a manufacturing plant to avoid buying new equipment in a misguided attempt to save money, with IT teams not realizing that the operational costs to troubleshoot problems and the associated downtime in a factory environment can result in even higher costs."

I love this! How many of you have suffered from this problem with your antiquated or unsupported fundraising databases?! (And it's kind of reassuring that commercial organisations have this problem too!)

6) "The big push for last year was solidifying the environment, and this year is all about pushing out into the applications and into the manufacturing space to impact yield inventory."

This is just a small point to show that any new CRM implementation does not have to be rolled out to everyone or to manage all potential benefits immediately. Plan for future expansions in the subsequent years after your immediate go-live - you don't need to, and shouldn't try to do everything on day one.

Nine Costs to Remember when procuring CRM Systems

On the ninth day of Christmas, my truelove gave to me... Nine Costs to Remember when procuring CRM Systems

There are many costs which you need to take into account when procuring and then implementing a new CRM System or Fundraising Database. The following are the core costs:

• Software Licenses: Regardless of the type of license - perpetual vs monthly/annual (subscription) licenses, and concurrent vs named vs unlimited user numbers - you need to make sure you are comparing like-for-like across all your potential options, including any 'core module', additional modules/apps etc. (And that's before you consider and compare actual functionality and benefits.)
• Hosting/Storage: This can be different depending on whether you are looking at cloud or on-premise or third-party hosting. It is comparatively simple to cost at an "explicit" level but can be very difficult when looking more deeply. At a simple level, Cloud systems will probably include x Gb of storage with your standard price and then you pay extra for every additional Gb you need. Bear in mind that can add up, especially for larger databases. You will therefore need to work with potential CRM suppliers to calculate how much storage you will need - and then add more to allow for future growth. That can be difficult. With on-premise solutions, the explicit cost is of course the hardware and associated software - but the harder costs are the fact that your internal IT staff will need to maintain that hardware, do upgrades etc, which is why Cloud salespeople say Cloud is so much cheaper. And for on-premise, you should probably also allow for the cost of new servers every n years, depending on your organisation's policy.
• Internal Project Team: Except for small database implementations, you will almost certainly need specific costs for an internal project team, back-filling etc. (See Christmas Tip #6 for a few more thoughts on this). Such costs could vary depending on the type of software or supplier you select.
• Supplier Professional Services. This has the potential to be a wide range of costs - and one of the highest budgets. For example: consultancy, system design, development and customisation, creating blueprints, report writing, installation, support with UAT, post-live support, project management etc etc. Read another blog post of mine about how you can compare suppliers' professional services costs and what to look out for.
• Data migration: I have separated these from the rest of the Supplier Professional Services because, for any database larger than a simple spreadsheet, they can be harder to cost up-front, until a supplier has had the chance to look at your existing database in detail. For larger projects, this won't come cheap - do not under-estimate.
• Training costs: whether it is internal, using a third-party/contract trainer or using the supplier's staff.
• Integration: If your project involves integration of any sort (and it almost certainly will if it is for fundraising), from receiving online donations on your own website or data from JustGiving, through to importing data from fulfilment houses and exporting to finance systems - and more - then these costs can start to add up. I have written several posts specifically about integration over the years. Bear in mind 'integration' can mean different things to different people and to different suppliers so be careful when comparing costs and approaches. Talk to all suppliers in detail to clarify any uncertainties.
• Annual (on-going) Costs: Software Support/Maintenance - Most traditional fundraising package suppliers charge x% per year for software support/maintenance but that often includes future upgrades too. With CRM systems, the business partners you implement the software with will also likely charge annual support costs which will vary depending on whether they are selling a 'template' solution, developing from 'vanilla' etc. And Software licenses - if you are paying on a monthly/annual basis then you will of course continue to pay such costs every year. To compare, annualise them and compare over n years.
• Other Costs: Okay, I know this category could include anything but that's the point! I do also want to emphasise that there are any number of other, additional potential costs in a fundraising or CRM implementation, from hardware and workstations, to PAF and banking validation software, other people costs, paying fulfilment houses and other suppliers to change file formats and so on and so on. Find what you need and build them in to your final budget.

Seven Free Apps for CRM Systems

On the seventh day of Christmas, my truelove gave to me... 7 free apps/software which can be used with Charity CRM Systems

I am always cautious about saying that software is free, because so often there are some sort of costs associated with it, even if the price tag itself is zero. With that caveat in mind, here are some free apps/software which I hope could be useful for CRM and fundraising software implementations:

• Power BI Publisher for Excel: Microsoft's Power BI is a great tool to enhance the visualisation of data. Using it, you can take snapshots of your most important data/insights in Excel, such as PivotTables, charts and ranges and pin them to dashboards in Power BI.
• Free Raiser's Edge Plug-ins from Zeidman Development and SmartTHING: David Zeidman and Warren Sherliker are both fantastic developers of plug-ins and customisations for The Raiser's Edge. And although they charge for their developments, they also offer some apps and 'lite versions' for free. If you use Raiser's Edge then their websites are both well worth checking out.
• Free Salesforce apps: The Salesforce AppExchange has lots of free apps, some definitely better and more useful than others, but it's a great resource for Salesforce users. There are email integration tools, dashboard apps, data management apps and more.
• XrmToolbox for Dynamics CRM: If you already use Dynamics then you may know about this add-on already, but if you don't use it or if you are thinking of using Dynamics then this is a wonderful free tool to know about. As it says on the their website, "it is shipped with more than 30 plugins to make administration, customization or configuration tasks easier and less time consuming". Good stuff.
• Gift Aid calculator for your website: This is a free piece of Javascript which I designed myself some years ago to show donors how much their donation would be worth with Gift Aid. Anyone is welcome to use, amend and incorporate it as they wish; it is probably used mostly by small-mid size charities who want a quick and easy (if not so beautiful!) solution.
• Free CRM Software: CiviCRM and KindLink. CiviCRM is an open source CRM solution for NFPs and KindLink is a recent addition to the charity market for cloud CRM software. However, I urge you to remember that just because the software is free, it does not mean it is zero cost - read my specific blog post about this - it's old but still relevant.
• Talend Data Integration software: Talend has an Open Source version (Open Studio) as well as a paid-for commercial version, but the open source version is still extremely powerful. It will help you integrate data between different sources and your CRM system. But be aware it is not simple software - you almost certainly will need a dedicated expert to use it.

If you want to recommend any other free software/apps etc then please do add them in the Comments below.

What Small Charities Need to Know about CRM Systems: Free ebook

I have just published a new, free ebook:  What Small Charities Need to Know about CRM Systems. Buying a new CRM system or fundraising database can be a daunting experience for any NFP organisation, let alone a small charity. And although I publish a lot of information on this blog which I hope is useful for all charities, there are some points which I think smaller organisations need to particularly be aware of or specifically consider. So I have brought these issues together into a new, free ebook.

Which in some ways was quite difficult! Because when I read back over my blog posts, so many more of them are equally appropriate for small charities too! I have therefore limited myself to just twelve areas which I believe should give a small charity a solid understanding of what they need to know about CRM systems and fundraising databases. But if you want to know more, then there's lots more on all my other blog posts.

Who this Book is Intended For
The book has been produced for people whose day job is not the procurement or implementation of new databases - which for small charities is probably almost everyone! And you do not have to be technical to understand it. It is for fundraising managers, chief executives, trustees, fundraisers, office managers, volunteers and those working in supporter services, but of course I hope it is equally useful for database staff and charity IT staff too.

If there are any points you think I should have included in this book then feel free to add them in the comments below.

How to Download the Book
You can download the book from my website: http://www.itforcharities.co.uk/free-ebooks/.

Integration Costs: Where to Start - and Where to Finish…?!

 

Integration is one of those words which can mean so many different things to different people. So for the purposes of this post, I don’t mean integration with third-party software such as Office or PAF software, but rather the need for data exchange or synchronisation between your new system and other data sources/databases. And as such, for any significant new database you will almost certainly have some integration.

As such, the sort of examples which you may therefore want to consider when integrating your database with other data sources include: receiving online donations, event registrations or any other data from your own website; data from JustGiving, VMG and other peer-to-peer fundraising websites; other supporter engagement websites (e.g. Engaging Networks); data importing/exchange with fulfilment houses; and data exporting to finance systems.

Sadly, the costs for such integrations can start to add up and they ain't necessarily cheap. So, a few key things to consider are:

• Have you identified all your external data sources? Do so, in order that you can definitely decide on the best approach(es) for integration, so you can prioritise and of course to make sure you don't miss any critical data feeds.
• When implementing a new CRM system, just because something was integrated in your existing (legacy) database, doesn't mean it will be easy to integrate it in your new CRM, at least not necessarily on day one.
• Do you really need real-time integration? People often say they do, but how critical is it? The reason you need to ask is because real-time integration usually means higher costs and more complex integration
• As such, 'batch process' integration is still more popular than real-time for most charities, and even for many corporates.
• Custom-coded integrations are barriers to change: especially for small organisations. This is because they are more complex and more specialist to create and far more time-consuming and expensive to change later. Keep it simple for future simplicity.
• You don’t need to make exclusive choices on integration - you could do one integration in one way (e.g. integrating your website and your database using web services) and several other integrations another way (e.g. batch imports from csv files).
• Watch out for "integration transaction" costs when implementing APIs. If you do go down the route of using API services for integration then some systems (e.g. some cloud CRM systems) will charge extra if you go over x transactions per day. And although the starting point of charging can often seem like it only kicks-in with high volumes, a single "integration transaction" through an API is not necessarily, say, a single financial transaction (donation) from a website; i.e. using an API to add a single donation to your database might involve multiple API transactions.

The new world of cloud storage - do you really need ALL your old data?!

Traditionally, when moving from one fundraising database to a new one, charities tend to migrate all their old data across - or very nearly all. Sometimes, small sub-sets of old or truly unneeded data may be left behind, but in the main, every single donation, communication, appeal record etc and every entity and every field is transferred as is to the new database.

Why? Well, understandably, fundraisers and marketing staff are worried about losing granularity of historic data, of not being able to do true and useful RFV calculations or similar analysis on summary fields, of not being able to look back at why someone responded to appeal X or came to event Y. And the thought of either not keeping their data in the most granular state possible, or even not transferring it at all, has been a complete anathema!

But recently, this is something which is being challenged. This is partly due to cloud CRM systems charging for extra storage, partly due to some performance concerns for complex processes on very large systems and partly to mitigate some of the risks and complications of data migration. And partly it is just good business practise to challenge such assumptions.

But Why?!
But just as pertinent a question for me is: Why - Why do you need ALL your old data? Really - why?! I mean, are you really going to look back at someone's communication history from ten years ago and want to see that a donor was sent a second letter because a particular acknowledgement letter didn't reach them first time? Do you really need to know that someone was invited to an event twelve years ago but didn't respond? I'm not sure if you do…

And although I completely recognise the need to keep a granular donation history for at least a set number of recent years (e.g. at least four years for gift aid claims), at what point are your fundraisers not going to use such data for segmentation and marketing analysis? Five years? Six maybe? In which case, do you really have to be able to see each individual donation for older periods as a separate financial transaction on your new system? Or actually, could a summary be acceptable? e.g. a summary by year/campaign/gift type/whatever is appropriate for you.

Of course, there are some data items you would definitely need to keep, such as first donation information, maybe upgrade details etc, but do you have to have more than that for donations over a certain age?

And if you do, if you have to or if your organisation is too paranoid not to keep such data, then maybe you can store it elsewhere for when (if!) it is needed. For example, a separate data warehouse, maybe a simple SQL Server database, even a separate marketing software system.

And what about any old data which you still have on your system but which almost no-one in your organisation trusts and so doesn't use anyway? Does that really need to be transferred? Really?! And data accuracy in general - just how good is it over a certain period anyway?

Or, Should we be asking, Why Not?
Now. One could of course ask why we shouldn't migrate all data and that's a fair question. Storage does cost but is it so much more? And contemporary systems are so much more efficient now than older systems, why shouldn't we have millions of records in our new database?

Well, maybe because more data does add extra data management, does add complexity when doing segmentation and reports/analysis, can slow down a system when running such processes, can make screens slower to load when they have lots of historic information, can make data migrations more complex etc etc.

I think it is an interesting challenge - one I encourage you to consider!

Why I want charities to spend money on suppliers' professional services

 

There sometimes seems to be a keenness amongst CRM/fundraising software suppliers to tell charities that they can implement their software by only spending a bare minimum on their professional services - or even none on some occasions. When I see this, I worry. Why? Because I want charities to spend money on suppliers' professional services. And there are good reasons for this:

• First off: I think that a good supplier offers many benefits by providing professional services. They shouldn't just be a 'software company' that is giving you software and expecting you to use it just like that. I want a company who understands our sector, who gets fundraising, who can provide added value with their services. This is good for the implementation and good in the long-term. Those are the companies who will want to work with charities and enhance their software for charities over time.
• Continuing that theme, I do think some suppliers undersell themselves in this way. I have met knowledgeable and smart people working for suppliers who I think could bring so much to a database implementation at a charity. Why wouldn't we want that?
• The suppliers are the experts at using their software - they know their system. After all, how do you know what is the best way to do something in the supplier's software if you have only just started to use it? What is best for your charity and your situation? The money you spend with them on their services should ultimately save you time and effort, ensure you are set-up better for your fundraising/services and mean you can raise more money/dedicate more time to services.
• You need people to help you. Someone has to. And either you buy-in contractors and specialists or you use the supplier. Implementing fundraising and CRM systems is not easy - it costs money. (Even if the software is free!)
• And then there is data migration… except for the very smallest implementations, you are always going to need to get your data from your old system into your new system, and unless you have lots of capacity and time at your charity, and unless you know the new system well, then the best people to do this are those working for the new supplier.
• If you are told by a supplier that you don't need professional services from them, then what are such companies actually offering that is so simple that you can apparently use it almost of-the-box with no work needed, yet so powerful that it can manage all your requirements? That's how it seems to me that some salespeople present their systems and I'm just not sure that's feasible.
• Are the suppliers not providing any project management services to manage their side of the implementation?
• I suppose there could be a caveat to some of this if you are a really small charity – although even then, as I have said before, such charities won’t have the in-house skills to be experts so they really need a supplier to help. 
• The only situations where I think you might not need to spend money on a supplier's professional services are (a) where you might have a different sort of approach with open-source systems such as CiviCRM if you really have in-house experts, but for many charities they won’t and therefore they will still need the Civi Experts; and (b) similarly, if you buy something such as Salesforce, kick-off with their vanilla version and, again, you do have in-house staff who already know the system and who could then do much of the work themselves. However, even in this scenario, such staff are likely (at this point in time) to still have limited exposure to implementing large CRM system at NFPs, so there could still be the benefit of using the suppliers' professional services even in these instances.

I’m just not sure what I think about suppliers who say you can do it all yourself and don’t need their input. They are either amazing or maybe, er, not giving you the full picture…

Only pay for your new database if objectives are met? How does that sound?!

Cloud CRM Supplier, Workbooks.com, recently announced an innovative approach to implementation pricing: Customers now pay half project fees upfront and if objectives are not met then they do not pay the remainder. And I’m wondering if this is a model which could be brought to CRM and fundraising database implementations in the NFP sector?

Of course there are challenges to this approach, the most obvious being, How do you set the objectives so that they are appropriate and fair to both the vendor and client? And measurable.

Workbooks.com say about this process: “SME CRM projects often fail because businesses struggle to set goals [so] Workbooks helps set objectives.” Which rings true. But set the objectives too "low", which of course the supplier should be able to meet more easily, and the client won’t get any business benefits from the implementation; too “high” objectives and the supplier won’t be able to meet them and thus it won’t work for them (or the client...)

You also have the potential issue of a client not "working hard enough" during the implementation so that objectives are not met and thus they don’t have to pay half the fees. And although that is possible, I think this might be mitigated and “self policed” by the client’s management team wanting to see results from their investment as soon as possible and not expecting there to be delays in benefits because of lack of impetus. And if there is a proven, expected ROI from the implementation (perhaps more likely in commercial CRM implementations than nonprofits) then why would a client want to delay that? This though, is a risk I suspect the supplier might have to accept.

On the other hand, a client also has the risk that a supplier might just focus their efforts on the key deliverables which would mean the objectives would be met and not "care" about other aspects of the project; but, providing those objectives are good for the client and mutually desirable to both parties, then that might be no bad thing as a starting point.

Indeed, the potential benefits of this approach are attractive. In theory, such a process could therefore mean you could get a very good scenario: because the client is of course going to want to get as much benefit as they can out of the implementation, and therefore be keen on pushing the supplier to provide “higher” objectives, but if the supplier keeps this in check so that the targets are achievable (and therefore they will get paid) then the client should also implement something which is not beyond their means. And over-expectations and under-achievements are the bain of many a CRM implementation.

It should also give clients some belief in the supplier's workload and project approach. If a supplier doesn’t match-up to expectations then of course they won’t get that part of the payment. That said, I suspect many clients would rather the supplier did meet their objectives and would rather they didn’t have to chase the supplier to do the work, even if there is a financial benefit to them if the supplier stalls.

I also wonder whether this model takes a step towards the mythical “partnership” which CRM suppliers love to talk about during sales processes, because this model would have to be a partnership for both parties to benefit appropriately.

The key to the success or otherwise of this approach is of course the ability to set the correct, achievable, beneficial and measurable objectives/goals/benefits of the CRM implementation. But that really shouldn’t be beyond the wit of smart and willing people who all ultimately want the same goal.

So, fundraising database suppliers, charity CRM solution providers, what do you think?! Have I missed any critical points? And who’s up for it…?!

How do you compare like-for-like on CRM Suppliers’ Professional Services?

 

I’ve recently had several discussions with charities and database suppliers about how difficult it can be to compare different suppliers’ Professional Services during a database procurement. This is partly in terms of comparing the specific services/options they are offering, but of course it is often about being able to compare like-for-like in terms of cost.

The charities have thus been confused or surprised that one supplier can claim to do something so much more cheaply than another; and some of the suppliers have themselves been cheesed off that a competitor has quoted so much less when they really believe that their competitor can't come close to offering the same services as they are doing with such a budget. (Some database suppliers do have a fair idea of what some of their competitors charge for services). Which, sadly, can entice the first supplier to 'minimise' their options too when they know they should be recommending the charity buys more. And thus the charity can't compare all the suppliers' professional services equally.

This is of course one reason as to why some charities use consultants to help them with procurement because consultants do such work more often and can thus help their client compare like-for-like and with the knowledge of how specific suppliers work.


So, for the benefit of all, I've listed here a few tips as to how I approach this potential conundrum and some specific things to look out for.

• Comparing like-for-like is important as much as possible. I understand this is the core of the matter but the important thing is to break down the suppliers' services costs into comparable sections; e.g. Specification, Development, Deployment, Data Migration, Post go-live support, Project Management etc. It is quite likely that different suppliers may have different terms for the same thing (e.g. discovery phase or requirements document; configuration or development) but you need to understand that and thus be able to compare apples with apples. Ask suppliers to detail what they are actually offering in their written proposal and that should help you. But be aware that, say, if one company is offering 2 days training and another 10 days then that isn’t truly like-for-like, and the question therefore is whether one is under-estimating or the other over-estimating, or whether both could be right! See below for more thoughts on that awkward point.

• Ensure you include/consider all possible costs for all suppliers – even if some suppliers haven’t included them in their quotes/proposals. Some such costs will definitely be needed for all suppliers’ proposals (e.g. training, data migration), so if a supplier has not quoted for such an item at all, then ask them why not or make an allowance. That said, some costs may not be critical for all implementations (e.g. additional report writing, even go-live support for smaller projects) so in some instances it may genuinely be that some solutions will require different services.

• Comparing ‘traditional’, dedicated fundraising packages vs ‘generic’ CRM systems. I wrote a whole series of blogs recently about this, but in terms of professional services, for the “average size charity”, it might well be that some of the services required for the CRM systems are not needed at the same detail by fundraising package suppliers – and thus this aspect of the CRM systems will either genuinely be or appear to be more expensive. For example, a fundraising package may have Gift Aid, Prospect Management and income structure all built-in as standard, but some CRM systems may need to be configured or bespoked to manage these needs. (NB: this doesn’t make one better or worse! Again, read my blog posts giving a far more comprehensive comparison).
  
  Likewise, because CRM systems by their definition will need more configuration (but probably will have cheaper license costs), it may be more difficult for CRM suppliers to give accurate (or even ball-park) figures at the time of a proposal. They are more likely to need to do more work with your charity before they can provide such costs, and sometimes that discovery or feasibility work will be chargeable. Nothing (necessarily) wrong with that – but you need to build it into your cost comparison.

• Training: There can be all sorts of different ways of quoting for training, aside from the fact that one supplier may, say, recommend 3 days and another 12 days. For example, on/off-site training; user vs admin/power-users; “generic system training” (e.g. Salesforce admin training) vs system-specific; training all users vs train-the-trainer approach; and so on. Check each quote. And see below about my thoughts on dramatically different recommendations of, say, the number of days required.

• Integration with your website: Integrating with your website to automate data integration with your fundraising database for online donations, event registrations etc can really vary in the functionality being offered, the simplicity, ability, technical approach, comprehensiveness, customisation, automation and, thus, cost. Check out exactly what each supplier is or is not quoting for and how accurate they feel they are being about such pricing.

• Remember other integration; e.g. third-party software, data feeds etc. If one supplier does include integration costs and another does not, then check with the one who has not as to why not. It might be that some such costs are standard functionality and are thus not needed, or it might be a package offering they are providing; or they might have “forgotten” or just not included it.
  
  Integration can be one of the most expensive aspects of any implementation so don’t brush this under the carpet.

• Data Migration. This is one of the hardest costs to compare. It is one of the hardest areas for any supplier to provide a quote on unless they spend some time looking at your data or unless they have a standard cost and just accept that they may spend more time on some project than others in doing this work. Although I would personally be cautious of that approach as I would be wary of what they were really offering and at what level of quality. I personally prefer quotes specifically oriented at my client's requirements.
  
  You can therefore take the estimate the supplier has given you and balance that against the other suppliers, but I would also talk further to any supplier who has quoted significantly less than the others. Why have they done that? What does/doesn’t it include? Do you have simple or complex data? A single or multiple sources? Are they allowing for multiple trial migrations as part of the project and thus charging less/more? And so on.
  
  One simple if crude approach, unless you have solid reasons to think otherwise, is to take the highest quote of all your suppliers and put that against them all. This takes this out of the equation in terms of pure costs.

• Of course, some systems will be different. Some will require less or more configuration, even if both are fundraising packages. Some may require less/more training, and so on. Talk to the suppliers, talk to their customers when you take references, talk to other charities online, at events etc.

• Some suppliers are more/less expensive. Some will have different day rates, some will insist on more project management, some will have pre-configured solutions/templates, some will offer discounts. And so on and so on…

A good rule of thumb is: if one supplier has quoted for a specific service but another has not, then ask yourself - and then probably the second supplier - why this is. There may be a good reason for it - e.g. it may be incorporated in another cost - but if it is needed and they haven't included it in their costs then bear that in mind...

In general, if one company quotes a lot less the other(s)…
… then go back and ask them about it. There’s nothing wrong with telling them that other suppliers (although I wouldn’t personally, necessarily say the names of such suppliers) have quoted for a lot more, so why are they quoting so much less. They might be able to explain why you need less development time, or their in-house knowledge of your current system means that they know they can do something in less days; their software might be much simpler/limited in terms of functionality/customisation etc so they might really not need to do so much work on it (although you then need to remember that when comparing different systems...); or, for example, it might be that they genuinely believe you don’t need so much training.

Or it might be that they had a caveat somewhere else in their proposal which stated they were only offering x days training and that you would need more if you wanted X,Y,Z… You’ll then at least be able to compare better, and you can then decide if that was a genuine oversight by that company or whether it was bit disingenuous.

Do not assume that if company X has said you only need 10 days of their time, and company Y and Z have both said you’ll need 30, then X will ultimately be cheaper or better or right for you. Of course they may be - but it may be that they are offering less, both in terms of work and functionality, or they may be implying you “might” need more but haven’t included that in their “core costs”.

What should you do if you really have zero budget for a new CRM or Fundraising database?

As much as I always promote having an appropriate budget for your fundraising or CRM database, and as much as I try to enforce the understanding that free software doesn’t mean zero cost, I also realise that sometimes, in particular for smaller charities of course, you just don’t have a budget for a new system. So what should you do then?

Below are the key things I believe you need to consider and act on in such circumstances. They won’t cost you anything except your time and attention. Although even with that said, I struggle to truly say the whole implementation will be free. There are always additional costs: you will still need PCs, an internet connection, probably hosting for your database, maybe additional software and so on – so you either need to have a great benefactor or be a great fundraiser/negotiator, otherwise you will still need to spend money on those things.

Do note that these tips are primarily aimed at organisations who really don’t and cannot expect to have an appropriate budget for their database – so if you are a charity of any reasonable size but you are struggling to acquire a budget for a new system then, even though the following may help you, my first piece of advice is to re-visit your business case and determine why it isn’t deemed to be so important at your organisation. There is no point – for any size organisation – in getting any system, free or paid-for, which is not right for you, even if it is the cheapest one, even if it is free.

1. Get the basics right before you start looking for a new system
Remember that any database software is an enabler to help your fundraising strategy. Ensure you know what your strategy is now and for the next few years in order that you will know which CRM system is appropriate for you and what you need from it. And remember too that the database software is only one aspect of any database implementation – don’t think that you can just install a database and that will solve all your answers! i.e. a database is only as good as the data in it (i.e. how you collect it, data consistency/accuracy etc), it will only be used as well as your staff are trained to use it and with appropriate processes, and you will still need fast enough hardware and, if appropriate, a fast enough internet connection.

2. Treat your process for getting your new system as a ‘formal procurement process’, even if you’re not spending any money on it
I would still advise you create a document showing your requirements, I would still advise you research and find out about possible suppliers and, if appropriate, people who can help you (see below), even try prototyping one or two of the systems (assuming they're free, c.f. below), create a plan, engage the rest of your organisation and so on. Don’t just start using the first free system you find just because it is free.

3. Ideally, use a well-used package or CRM system – not a bespoke development
One of the key problems which charities have suffered from over the years is when a (well meaning) volunteer or “someone’s friend” has created a bespoke database in Access/Filkemaker etc. The problem with this is that they may not be around forever, they won’t necessarily understand your needs and they are re-inventing the wheel.

I would therefore look at systems such as Salesforce (free for the first 10 users), Zoho, CiviCRM, SugarCRM. They will all need time and assistance with setting up (see below) but they are all good, established systems; and they all have good online communities to help you. This means that if you or any other key people in your organisation leave in the future, then someone else will be able to pick-up your implementation much more easily than if it was a bespoke development. And you will get support and future enhancements. They are also good systems so that if in the future you increase your needs (and budget) then you will be able to build on them potentially without needing to change system again.

4. Keep it simple
Complexity (and over-complexity) brings cost. If you are looking for a free system then I will generally assume you do not need sophistication. If you do require more advanced solutions then free may not be right for you. So keep it simple: it will be quicker to implement, easier to use, easier to support and change in the future and you will get better results. And that has to be your ultimate goal.

5. If you don’t understand databases, don’t set it up yourself
Whilst I normally don’t advocate the use of volunteers for any significant database implementation, if you have never used a database before or you don’t know best practises in this area or what they can really do for you, then find someone who does and get them to help you. You may have a database-savvy staff member in which case they may be able to help. Otherwise/additionally, there are a number of places you can find free support and assistance from professional IT staff, including IT4Communities, the Do-it Volunteering database or even the WCIT. Or for really small charities, maybe even approach your local college for students requiring work experience? And don’t forget your trustees for contacts and input!

6. Document everything – the configuration of your new system and your processes
During and after the implementation, if you get someone to document what they have done then anyone else following them will be able to make changes and support your databasse much more easily. If you get someone to create proper, written down processes for you, then you will be able to use the system more efficiently and your current and future new staff can be trained.

7. Commit to the project
I have come across too many organisations who have started to use a free database without really committing to it, and in no time it has become a white elephant (all be it a no/low-cost one). But that won’t help you, your charity, your fundraising or ultimately the cause you are trying to support. So don’t think that just because you are spending no money on it, it will all work beautifully, immediately, first time and without any of your time. You won’t be able to press one button and get the database to tell you who are your best donors, or send a targeted email campaign or find out who you should be speaking to next week if you don’t do the groundwork. Sorry! Commit - it's really worth it.

CRM systems vs Fundraising databases: How do costs compare?

This is the third post in my series on The Impact of Generic CRM Systems on the Fundraising Database Market.

In part one of this series, I discussed the potential benefits and issues of these systems. But I deliberately left out two of the most key questions: how long will it take to implement the systems? And how does cost compare to dedicated fundraising databases?

The reason I decided to address these points in a separate post is partly because they require more dedicated consideration but also because they are, understandably, two of the more contentious factors for suppliers from both sides of this fence. Suppliers of dedicated (“traditional”) fundraising databases will of course say one thing and the new generic CRM suppliers will say something else.

So this is my attempt at a fair appraisal of the two approaches. I have no doubt that people will want to agree or disagree – that’s fine, please do so constructively in the Comments below! – and I have no doubt that there will be genuine reasons as to why some of my arguments may be quite rightly challenged in some instances, but hopefully they will give charities and NFPs a better understanding of the sorts of things they need to consider.

And the bottom line, as with any database for any industry, is that there are so many variables in any CRM implementation that there is no one answer – in fact, if you were to ask me point blank, how much will it cost, then “it will depend” will be my most common answer. And it will depend - on everything from functionality required and breadth of data you want to store, to the size of your organisation and your in-house skills.

Bear in mind also that most my points below are mostly true for the “mid-size” NFP, which many charities will indeed fall into. For large charities, the implementation costs and time are going to be high regardless of whatever sort of solution you go for, and for small NFPs, there are amazingly low-cost fundraising packages or you may be able to implement a new CRM system quickly with very low implementation costs.

However, here goes nothing for giving you my views…

Cost
The reason it can be difficult to compare the cost of dedicated fundraising packages and the new CRM systems is because we have to remember the Total Cost of Ownership (TCO) for any procurement – i.e. it is not just the initial cost of the software which you must pay, but everything else: implementation, configuration, consultancy, training, data migration, third-party software, hardware/hosting, database/web integration, on-going support, even internal support needs. And much, much more. (I have published a document on Slideshare which looks at How to consider all costs in CRM procurement).

But the main difference in cost structures between the two types of system is that the dedicated fundraising package will (generally) have higher software license costs (i.e. cost per user) but because the fundraising functionality is already built-in, many implementations will not require much additional development or implementation work.

Whereas, with the new CRM systems, the basic software licenses of the CRM software itself can be extremely cheap (even free for open source systems such as SugarCRM or for 10 licenses from the Salesforce Foundation), although you also need to be aware of the on-going annual costs of not just the CRM system itself (i.e. Salesforce, MS CRM etc) but also of any third-party apps or 'templates' you use. Such costs can start to add up. However, the good thing about those is that you (usually) only need to buy a license for each app for just the number of user(s) who will be using them. e.g. Even if you have, say, 10 users overall on the database, if you have an email marketing app and only 2 people need to use it, then you may well only need to pay for a 2 user license for that app. (It's interesting to compare such annual costs with the annual support/maintenance costs of the 'dedicated' fundraising databases - depending on your requirements, they might not always be so wildy different...)

However, the main cost for these generic CRM systems will come in the implementation: and all the discovery work, spec documents, configuration/development and associated costs with all that. Even for the “templated” versions, they will either have a cost for the template and/or will still require additional work on top of them.

Unfortunately, it may be especially hard during a procurement to know the implementation costs of the generic CRM systems, because, whereas with dedicated fundraising packages, almost all suppliers will be able to give the “average size” charity a fixed cost or pretty-near estimate at an early(ish) stage, because CRM system by their definition will need more configuration, it may be more difficult for suppliers to give such accurate (or even ball-park) figures. They are more likely to need to do more work with your charity before they can provide such costs, and sometimes that discovery or feasibility work will be chargeable.

And for these reasons too, the 'explicit' cost of implementing a CRM system in particular, could be far lower if you don’t use a third-party supplier – all you have to do is buy the licenses and off you go. Of course, it isn’t quite as simple as that – there will be all sorts of other 'implicit' costs and different risks doing it in-house and someone in your organisation will still have to implement the system: design it, configure it, support it and so on. And there will of course therefore be an implicit cost in doing that.

Speed of Implementation
In theory, a fundraising package with all its pre-defined fundraising functionality, could be implemented quite quickly for the “average charity”. Of course, you will still need to consider business processes, have consultancy, do data migration, be trained and so on. But if you don’t need much changing from the standard system, then the time constraints can more often be your own internal resources as much as the supplier’s.

For generic CRM systems, it is extremely likely that you will need some configuration and bespoke work done on them, and as I’ve said already, even if you start with a templated version. And if you start with the vanilla version, then you will definitely need such time. Of course, again, some of this will be the same as per fundraising packages: the need for consultancy, reviewing business processes and so on. But the difference is likely to be that, after any initial consultancy on your requirements, even if you need standard fundraising functionality such as Gift Aid, then on a vanilla CRM system this will need to be configured or programmed by your supplier.

And thus we can see immediately that this will of course impact on costs…

All that said, for generic CRM systems, for simple fundraising requirements, where a supplier can provide a templated solution or integrate with appropriate third-party apps for that CRM system, it may well be that implementation timescales can be brought down. (In the same way that dedicated fundraising packages will have such functionality built-in…!)

Sitting on the Fence
I know that, to a degree, I am sitting on the fence in terms of giving you an answer to such a critical question. But as I said above, this is because there is no simple answer! And every procurement and implementation will be anything from slightly - to very - different. The point is, if you are going to buy a new system, then you need to understand and consider the different approaches and why it isn’t as simple as any supplier telling you that they can do it best because dot dot dot.

Do remember Total Cost of Ownership and do remember to compare like-with-like as much as you possibly can.

Part 2: Different Ways You Can
Implement Generic CRM Systems For Fundraising

 

Part 4: Specific Things to Consider
When Procuring a Generic CRM System

The Successful Spend Ratio on Database and CRM Projects

Successful database projects are 50% about people, 30% process, and 20% technology: so why do so many projects have such a high budget on technology and such a low budget in comparison on people and processes?

Why are these ratios important? Well, there is no point in just buying a database and that’s all – it won’t install itself, it won’t configure itself and it won’t know how to manage your processes on it. And yes your staff and the CRM supplier can do that, but in order to do so they will need time, resources, maybe back-filling of existing roles and so on.

Of course, the database is not unimportant, but there are other factors which are more important in terms of ensuring successful usage and implementation of databases. I.e. If the data is not clean, useful and comprehensive then it doesn’t matter how good the hardware or database software is; if staff are not trained and business processes put in place, then, again, even the best database may struggle to correct such issues; and so on.

And for implementations of new databases in particular, the need for project management cannot be underestimated, nor the influence and importance that the data migration will have on at least the initial go-live period of any new system.

Whether or not the specific figures detailed at the start of this post are always exactly this ratio, they show the correct approach. So do take this into consideration when you are budgeting for your new database. With some of the CRM systems available now, where software licenses are reducing in cost and where hosting is offering good cost-benefits, you might find you can spend appropriately more easily on people and processes. But even if you don’t find yourself in that situation then do review your budget and ask yourself if it is definitely correct.

I understand it is sometimes far more difficult to ask for money for spending on the people and processes when the software and technology appears to many senior managers at charities to be what you are really buying, but fight your corner and explain how important the other two factors are.

Successful projects and procurements work because wise organisations understand this ratio is critical.

---

This is just one tip taken from my ebook, "101 Tips on How to Buy Fundraising Software and Charity CRM Systems".

Also now available on Amazon.

Getting Discounts on CRM Software: It's Usually Good News But Be Careful...

If you watch The Apprentice on the BBC then you will have seen the would-be apprentices desparately bargain for discounts in last week's episode. (1p off a top hat was a record low discount for any series, I think!) And quite understandably, some of the suppliers in the program refused to give any discount at all: this is the price of our product, they said, so pay it. Fortunately, in in the "B2B" world of commerce, discounts are more readily expected and sometimes given. Although it is an interesting point: if a software company is selling their database for x then that is obviously what they think it is worth, isn't it? And if they are prepared to offer a discount, then why wasn't that the price in the first place?

So if you are buying a new CRM database for your charity then do keep a few things in mind if you expect or even get offered a discounted price:

1. Purchase time is the best time to get discounts, so if you expect to increase the number of your licenses later, bargain at that time!

Suppliers will often give discounts when you are actually buying their system, whereas once you are a client, it will be far harder for you to bargain at that time to get discounts on further licenses. So, if you know that even though you are going to start with n concurrent users but you feel you may well increase that number within, say, 6 to 12 months, then see if you can negotiate a discount on those additional licenses at the time of your purchase. You need to agree a timescale for when any such discount structure is valid – it’s not fair to expect a supplier to offer an open-ended deal on that.

2. If a supplier provides a discount on a previous quote, check you are still getting the same software and services

If you do get an initial quote and then, for whatever reason, the supplier offers you a second quote at a discounted amount, then the first thing you should do (unless you know you are getting a different proposal) is check with a fine toothcomb if you are getting exactly the same proposal as you did first time around – exactly the same software with the same licenses and modules, and exactly the same services with the same number of days, level of support staff and so on. And if so, great – that’s a proper and decent discount. But if not then go back and point that out to the supplier – a discount that has actually cut down on software or services isn’t a discount at all, it’s a revised quote for a different solution. Give them a chance to explain or make amends but if they won’t then you need to consider whether the new quote is really what you want. Don’t get hoodwinked!

One other thing to consider around discounts is if a supplier offers you a huge discount and it is pretty much for the same solution as they were previously proposing. Especially if they have done this unprompted because you have just told them that you don’t want their database. This may sound like a wonderful occurrence (!) but do take a few moments just to consider why they are doing that. Is there a genuine reason that they are offering you such a large discount or is there some desperation on their behalf?

I would suggest that you do consider carefully before you sit down with them again. I do know of instances where this has happened and it has worked because the supplier has been able to explain the commercial reasons for such a difference but in general I have found that clients are quite suspicious of such instances and even a little disgruntled. (Why didn’t they offer me that price in the first place? How much profit were they making originally?)  So just tread carefully, research other sales they have done, discuss it closely with the supplier. And if at the end of that you are not comfortable then walk away – it isn’t worth the risk; but if at that point you believe beyond any reasonable doubt that you really are getting a good deal from a good supplier then go for it!

3. Why and when should you expect a discount as a buyer?

Of course, there are very good reasons for suppliers to offer discounts: for a new supplier in the market, they may want to encourage early adoption - also helps justify the higher risk for you as a client; for a salesperson who is trying to meet their quota, there may be times when they are prepared to take a hit on the price; for competitive reasons to beat a signficant competitor for a significant bid; as a final piece of encouragement for you to sign before a given date; in recognition of entering a new sector for the supplier and so on. And of course, if the supplier normally sells to for-profit companies then they may give a discount to charities and nonprofits, which is obviously fair and great to have.

What I don't think is so valid for buyers to do is to just say, "Give us a discount and we'll be a reference site for you". I would hope that whatever the case, if the supplier ultimately does a good job, then you would consider being a reference site anyway.

I think discounts work well when, as a buyer, you have selected a preferred supplier but that supplier might have quoted a significantly higher cost than your second choice. In which case, it is perfectly fair to go back to your preferred supplier and ask them for a discount. Even then, depending on the cost difference, I wouldn't necessarily expect them to meet the cheaper supplier's quote - after all, they might cost more because they are better - but you could certainly expect some allowance to be made.

How to Consider All Costs in Database Procurement

Because most charities will only make a significant investment in a new database system every few years, they don't always consider how they need to compare the costs of such purchases. And it is vital that when comparing costs you don't just look at the cost of the software - you must look at far more than that. One useful approach to help with that is to use the Total Cost of Ownership (TCO) cost model. This post provides a basic introduction to this.

Why is TCO Important?
Firstly, you must remember that the new database software is only one element within all your potential costs for a new system, and secondly, that it is not just the initial cost of the system which you need to cost – you should create a TCO for, say, 5 years.

This therefore involves the comparatively simple task of comparing ‘direct’ costs such as software, the supplier’s implementation services, additional hardware etc, but optionally you could also incorporate the more difficult/complex task of additional cost factors such as internal IT HR support costs, electricity, de-commissioning etc. In practise, most charities will find that even if they just compare the more direct costs, that will still help significantly, and it will probably only be the larger organisations or charities who implement  large CRM systems who will incorporate the additional cost factors.

Costs you Should Consider
Below, is a list of ‘direct’ costs which you should definitely be able to calculate when comparing database systems (although different suppliers may of course call them by different terms). Although I would expect most/many to be needed within most CRM projects, you may not need them all or you may of course need other factors not listed here. Use it as an example and basic model – break it down in the best way for you so you can compare and contrast the costs. By doing this, you can compare different suppliers’ costs like-for-like.

The Database Application Software (and associated software)
•    Core software / application software (including the number of concurrent users/seats)
•    Additional modules
•    Customisation / Bespoke programming
•    Reporting software
•    Web software / web services

Implementation
•    Functional Specification / Analysis & Design
•    Installation
•    System configuration / System build
•    Implementation
•    System Integration – including synchronisation with your web site if appropriate
•    Supplier’s Project Management
•    User Acceptance Testing support
•    Training (SuperUser training, end-user training, training materials)
•    Go-live support
•    Data Conversion (estimate or allowance)

Annual Support (Maintenance)
•    Application software Annual cost
•    Additional software annual costs
•    Hosting costs (if applicable)

Third Party software
•    E.g. PAF software, banking software, new Office software needed

Underlying Database software
•    E.g. SQL Server
•    Client Access Licenses

Hardware and associated (operating) software
•    Server(s)
•    Clients
•    Communication links
You might also need/want to add annual maintenance costs for any such hardware and infrastructure.

How to use Your Calculations
Put them all in a spreadsheet, each cost as a row and the different suppliers/options as columns. After doing this, you will have two “broad” costs – a first year cost (initial implementation) and annual costs for each year thereafter. Thus, you can get a 5 year TCO; and thus you may find that what seems to be cheaper/more expensive in the first year may be more expensive/cheaper over the 5 year period!

More Comprehensive TCO
In terms of additional cost factors which help create TCO at a more comprehensive level, you might include the following. Some of these will be the same cost regardless of whichever supplier you select, or they might break-down into a few groups (e.g. hosted vs non-hosted solutions).

•    Purchasing process
•    Operating Costs
•    Project Management
•    Internal IT staff
•    Internal Database/Marketing staff
•    Back-filling for project staff
•    Management time
•    Electricity and air-conditioning requirements
•    Floor space
•    Outage costs
•    Back-up/Recovery cost
•    Risk cost
•    Opportunity cost
•    Additional hardware such as UPS, racks

And a Final Note on Costs
Cost is of course a significant factor in the decision of any procurement for a charity, but please bear in mind it is not the be-all-and-end-all! You need to weigh it up against all the other important factors of any database implementation from functionality and usability through to the supplier itself and how it meets all your needs.

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.

Why Free Software Doesn’t Mean Zero Cost

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!