GDPR Doesn't Mean You Need a New Database

Last week, Civil Society reported that "almost 40% of charities are considering reviewing their current CRM system with the launch of the FPS [and] GDPR." My message to such charities is: hang on, wait a minute, do you really need a new CRM system or fundraising database? Buying and implementing a new system is complicated, expensive and takes up plenty of your resources. So before you do that, there are a number of things you should do first:

• Talk to your current database supplier. This has to be your first course of action. What do they recommend? What are their plans? If you have a "fundraising system/package" such as Raiser's Edge, thankQ, DonorFy etc then such suppliers will still want to be selling their software to other charities now and post-GDPR, so they will need to ensure their systems are compliant or they won't sell anymore.
• If you have a CRM platform (Salesforce, Microsoft Dynamics 365 etc) then you almost certainly will be able to manage FPS and GDPR on them but of course it could be simple or more complex depending on your current design, if you have access to any IP (Intellectual Property) issues etc. So, again, talk to whichever supplier/business partner implemented your system. And if you don't have any such relationship and your in-house staff don't know how to change your platform then call on a Salesforce/Dynamics specialist developer - there are lots out there.
• Talk to other users of the same system that you are using. If the above doesn't get you any joy then talk to other charities who are using the same system as you are. If you've got issues then other organisations will almost certainly be/have been in the same boat as you. Maybe they have already found a solution and can give you some tips; or if not, then maybe you can all get together and put some pressure on the developer to get something done.
• Talk to other charities who are ready for FPS/GDPR and ask how they've done it. Even if they have created a solution in a different system/platform to the one you use, it is quite possible you can learn the concepts of what they have done and see if you can replicate that in your database. You could even look at third-party specialist solutions such as Wood for Trees' Consentric Permissions or Syrensis' The Preference Centre.
• And do talk to a qualified professional about what you really need for FPS and GDPR (i.e. a lawyer, compliance expert, a consultant specialising in this area etc). I have read and seen too much conflicting advice over the previous months and 'data protection' is unfortunately one of those things where many people think they know what is needed but many people don't really... And it is one area which you can't afford to get wrong.

Finally, if it turns out that you must change your current CRM system/fundraising database then don't rush it. Do it properly, get a formal procurement process in place, implement any new system with a correct timetable and budget; and if necessary keep your FPS/GDPR data in a separate system in a consistent format which you can import into your new system at a later date.

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.

12 Key Lessons From My Last CRM Project

On the twelfth day of Christmas, my truelove gave to me... Twelve Key Lessons I Learned From Managing My Last CRM Project

I thought I would finish this set of blog posts with a quick-fire set of some of the most important lessons I learned from the last CRM project I managed. Each point really deserves its own dedicated blog post, but I hope they provide a succinct set of tips in themselves:

• Configuration not Customisation where possible: I have blogged about this before and it remains true. The more you can Configure and use the software's built-in tools and GUI to configure and define your system, the better. Each bit of Customised code will add cost, time, risk, pain and something you should try to avoid unless you can see real benefits, at least during implementation.
• Don't try to re-create your existing database: It is so easy to go down the path of replicating exactly what you do now but just in a new CRM system, when what you should be trying to do is use the functionality and approach and benefits of the new CRM system. If you have bought system X then use it as it was meant to be used. Long-term that will set you up so much better.
• Yes, ask users what they want, but then start with a simple base configuration and go from there: i.e. don't try to do every little single thing which users ask for, don't try to change every form on every screen for n different teams, don't bend and change the software in complicated ways when you are still learning and building it. Instead, get the basic requirements, use the software in as simple way as possible to get a starting point and then show the users that - if there are then things which you really have to change then you can consider them at that point or even post-live.
• Don’t under-estimate the challenge of data integration: Integration is hard, no matter how you do it. Think of all those external data sources you need to import, that other system you want to share data with/update from your new system. It takes time, effort and money. Some suppliers may have starting points for some things such as JustGiving etc and that's good, but you may still need to change things.
• Treat reporting as its own workstream: Reports are always one of the things in a project where you start off with great intentions and then as the project goes on, you can find they slip down the order of priority. I would recommend managing them in a dedicated workstream, with a dedicated member of staff leading on them. Remember: reports are one of the key reasons you have a fundraising/CRM system in the first place!
• Work hard at supplier relationships: At some point in your implementation, it is highly likely that something will go wrong and you will need to discuss something painful with your supplier. The better your relationship with your supplier at that point, the more likely you will be able to come to a mutually satisfactory conclusion. It needs work but it's worth it.
• Consider a Product Owner/Solution Owner: In a large CRM project with a significant timeline and budget, consider including a role of Solution Owner (aka Product Owner). This is a role for someone who understands not only the charity's requirements and strategies but also fundraising/charity requirements more generally, as well as CRM software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. The role provides a central point of contact for design understanding and fundamental decision making.
• You will always need more people on your team: As the project progresses, you will no doubt find that you could do with more people working on your project, although it could be that you don't know all the exact roles when you start the project. So think about this up-front, budget for it and bring on some roles as you go through the project. Ideally, have a budget for future roles but have an agreement with your project board that you can define the actual roles later. And backfill if you can - always good to up-skill both the people you bring on to the project and the staff who step-up to do the BAU whilst those other people are on the CRM team.
• Think about the post-live structure of your database support team ahead of time: It could well be that the roles you have in your current database support/CRM team will be different to those which you will need with your new CRM/fundraising system, especially if you are moving from a traditional/proprietary software to a CRM Platform,  Think about this as far ahead as possible and make plans.
• You can mix-and-match your approaches to cost within the project: There is always the question of whether you should go for a Time and Materials (T and M) or a Fixed Cost budget. In fact, you could mix and match even in the same project. For example, some of the development work might be T and M but the data migration could be a fixed cost. Etc.
• Post-Live: Use a Roadmap, not Phases. I will point you to my older blog post on this as the principle still stands. I believe that having a roadmap approach to post-live development is far better and more efficient than the concept of Phase 2, Phase 3 etc.
• The importance of fun in internal comms: When you are engaging all your users, staff and stakeholders with your regular communications (which you have planned, yes?), then think of the one word which many people would describe such comms. Go on, close your eyes now and do it... Okay, got that word? Was it... "Boring"?! Sorry, that is often how it is! So make your internal comms more fun: whether it is with more innovative emails, interactive demos, screens in the staff room, lunchtime meetings with food, competitions with chocolate... It doesn't matter so much what it is, but try to think what would make you read something you didn't want to read and do that.

Implement A Single Source of Truth

On the first day of Christmas, my truelove gave to me... Details on Why a Single Source of Truth is so Important

It has always been important for charities to have a ‘single source of truth’ for their core data, but if anything, it will become even more critical in the years ahead.

What I mean by this is that if you want to know a supporter’s latest address, their most up-to-date communication preferences, who is stewarding them in your charity etc; or if you want to know the average income from your last n appeals, your total registration information for your events; and so on… then you need to know that you can get the correct information by going to one source system.

If you still have more than one database which stores the same information, multiple spreadsheets which have been created by different users, or if your data integration processes from your website or other data sources are not working, then it is highly likely that you will get a different answer depending who you ask or where you look.

You need a single source of truth.

However, do note that this does not mean you necessarily need to have only one database or even the infamous 360 Degree View. You could well have multiple databases but as long as you have a ‘central system’ where your core data is collated then you should be able to get the figures you need. And, of course, you need to ensure that there are not teams in your organisation who have their own spreadsheets “because they're my records…”.

Depending on your database setup, the goal of a single source of truth may not be too difficult - it may be more about consolidating data flows and processes - or it could be much harder f you do have many data repositories and a lack of organisational control/understanding for where data is stored and why. One good option for medium/large organisations is to have a data warehouse where you can collate all your important data and where specialist staff can create reports for your KPIs which everyone will trust and know is right.

Make this need your first organisational New Year resolution.

Are charities really ready yet to take full advantage of CRM platforms?

 

So often during procurements and marketing pitches, the undoubted benefits of CRM systems are laid out by suppliers for charities. This is understandable and correct - why shouldn't charities know what they could be achieving and the benefits of such platforms.

However, I sometimes wonder if most charities, or even some are really ready to take full advantage of such technology. I don’t mean from a fundamental or standard operational angle, clearly those systems have every chance of giving charities what they want for the start of any such project. But how many organisations have the people, the time, the resources, the clarity, the strategy, even the budget to really take it a step further after the initial implementation?

This is not because I don't think that charities don't want to, I'm sure they do, and not because they don't have the vision or understanding. Again, I am sure some charities do and I hope such organisations are getting the tremendous benefits which such systems can bring.  But I wonder if that is still done by just a minority of NFP organisations.

Why not?
If you consider all those factors listed above then the one over-riding thing which I think has the most impact on this is: People. People are the problem and the answer. Because it is the people which make the difference in taking full advantage of CRM platforms.

Consider skill-sets. Clearly charities have had people supporting their fundraising and similar databases for years but traditional fundraising packages have needed different skill-sets to those which the CRM systems require in order to exploit them to the max. For example, whereas the fundraising packages were in many ways more limited, the CRM systems are almost unlimited in their potential. But to achieve that potential you need someone with Business Analysis skills to be able to find out from the users, the fundraisers not just what they want but to interpret those wishes so that they can be implemented in a CRM system. This is not often something I find in mid-size charities and only sometimes in larger NFPs.

Then you need developers. Sometimes this will only require comparatively fundamental 'admin' type staff who will simply need to configure a CRM system, but for the more powerful and far-reaching benefits you may need specialist developers who can code the systems and get so much more from them. And this will mean new skills, new programming languages and a new understanding of how to get the most from those advances.

All that takes management, planning, different team structures and a different sort of approach to the fundraising packages.

So if you do want and can employ such people, then that means the other factors which will be needed will follow-on: time, budget, strategic vision. If you don't have the right people then there's no need for those other things.

But it's still not necessarily just that...
There's also one more difference which charities need to adopt, and that's a new mindset. Many database managers of the traditional fundraising systems will sadly have become used to being limited to only being able to work within the constraints of those systems, finding workarounds or paying a lot of money to their supplier and even then waiting to get extra work developed for them - or even having to say No to users when they are asked to provide requested functionality.

So to find yourself in a position where you could now theoretically say Yes to so many of the things requested by your users is of course exciting, but it also means knowing how to progress such requests. How should you configure or develop the systems? How should you ensure you are definitely doing what is best? (Don't just do what is asked for immediately - question such user requirements to make sure they are definitely what is really wanted and what will achieve the best results. e.g. Don't just add another tick-box field…). Do too much too quickly and you may introduce confusion or not do things properly; too slowly and it won't have the possible impact it could have. Do it without planning and you could find yourself having to unravel things and start again. Do it without understanding of database development and you could end up with a worse system, more unmanageable than that which you started with.

Don't let any of this stop you from buying and implementing the CRM systems and then developing them. Just make sure you have got the right building blocks in place first. The right people.

When Users Don't Know What They Want: Keep it Simple

I have previously blogged about my belief that you should keep database implementations as simple as possible, configuring as much as possible and not customising etc. This post is a subtle but important variation on that: this post is based on my observation that much of the time end-users don't actually know what they want or what they could have - or even (completely understandably) what the software can do - and yet we continually ask them. (And even good business analysts may not always get to the crux of the matter). Unsurprisingly, perhaps, we therefore sometimes get a system which, when it goes live, is either far more complex than the user wanted, is not really what they expected, or you even get told, "Oh, actually, that bit wasn't really that important at all. In fact, we don't really do that anymore…"

So: why not give users the basics to start with, the as-close-to-vanilla as possible, and then adapt that later once they do start to really know what they want, once they understand the software and what it can do.

E.g.: Let's keep the forms simple, the data entry straight forward, the processes matching how the software has been designed. And if that means that a user has to do two or three clicks to achieve something rather than one, then that isn't such a terrible thing to have to do in the first place.

This should mean quicker, simpler, less risky, cheaper database implementations. And implementations which are likely to succeed. And happier users.


Thereafter, once we have gone live and the users realise what they have got, then they will realise what they have is either fine or, no, they really could do with process x being streamlined further or data items a and b being linked together. Great. Then do it.

Of course, this approach does require a strong project manager or solution owner, a good project board to support the PM when necessary and a clear, open approach to explain to the users that this is what we are doing.

Do note I'm not suggesting you just say No the whole time and hide all the really funky things the users actually do want and end up giving them the very bare bones possible. You can think a bit past that! Just be open and inclusive.

And of course, as I have written before, if you do take such an approach and if during your analysis and implementation you do find processes which would benefit from more automation or a more sophisticated approach - and which can be proved to have benefits to be that way - then by all means do it. Ultimately that is one of the great benefits of a CRM system so I am not saying don't do it at all. Just keep it under control.

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…

Curb Your Coding Keenness When Creating CRM

If you are implementing a CRM system, then, as much as possible, I would recommend that in the first instance you don't use "code" - or limit it as much as possible anyway. I know I have written about this before (Learn what your software can do before customising and changing), but it is such a useful, fundamental thing to remember, and there are so many more charities now considering and implementing CRM systems, that I wanted to re-iterate it again here.

To clarify: one can configure a new database, which is clearly essential and highly beneficial, but this means using existing tools and functions in the system which, for the most part, can be managed by just the software's "front-end" interface (i.e. drag-and-drop, using the standard GUI and the like). Indeed, some CRM systems can do this and still provide very sophisticated functionality and capabilities.

But as soon as you start writing code, "customising", bespoking a system, then that is what I would recommend you try to stay clear of, at least when you are first implementing a new database.

Why? Because customising takes longer, is more complex, needs more work, raises the risk factor, it will cost more, requires more specialist expertise, will be harder to change later, will be harder to maintain later, you may change things you will later learn you didn't need to change and so on.

Of course, there are good reasons for when customisation can bring benefits, such as automation, simplicity to end-users and integration, but I would always challenge exactly why this is planned in any instance. Just what are the benefits/time-savings/efficiencies? Can it really not be done another way, at least in the first instance? You can always do the customisation later if you later decide it really is worth it.

And if such discussions mean that coding/customising is shown to be a beneficial thing then great, let's do it. If not, keep it simple, configure the database, use a process and move on. Your project manager will thank me. And so will your FD.

The Importance of Report Designers during CRM Implementations

 

On one project I worked on, not long before we were due to go-live, there was some concern that a specific, highly important report could not be produced because of the fundamental, underlying design of the CRM system. And it made me wonder how this could have happened - that such an important factor had not been fully considered until that point. It turned out that the reason was because when the database was being designed, the report designer - i.e. the person who creates the reports, not the software - had not been consulted when they could have provided invaluable input.

When I thought more about this, my first reaction was to think that this should hopefully be a rare occurrence. One would trust that in most instances, whoever was designing the database - whether a person, a team, a company etc - would know the key reports which were required and would thus design the database so that such reports could be created. Plus, in classic systems design, one often starts with asking what reports and information are wanted and thus we work backwards to work out what fields and data need to be recorded in order that such reports can be created.

However, with larger or more complex implementations, with projects with larger teams, and also with the new CRM systems which now offer so much more flexibility with their design, I've realised that such a requirement could easily slip through a hole. It is quite feasible, if the correct person is not consulted, that a database could be designed without true understanding or consideration of some reports. Or perhaps understandably, whoever is designing the database was told by a 'third party' as to what a report needed to show, and thus they hadn't got the full picture.

This issue can also be exacerbated when a charity is implementing a new database where no-one in the charity necessarily has the in-depth experience of report creation on that system. (By the way, in this instance the charity may have to hold their hands up to accept their share of guilt as this isn't necessarily something which should be aimed purely at the supplier...)

So my advice:

• when designing databases, do make sure reports are considered early in the design phase;
• engage the relevant report designers as soon as possible, and if you don't have one in-house then consider contracting one even for a short period to do some 'sense checks' early on; 
• introduce a specific 'report workstream' in the project so that reports, outputs, mailings et al are specifically considered at all times; 
• and don’t underestimate the time or importance of this factor.

After all, if we can't report on the data or get the data out of the database in a useful format, why are we using the database in the first place?

Learn what your software can do before customising and changing

When implementing a new database and you're at the stage of defining the final specification with your supplier, it is often tempting and exciting to ask the supplier to customise the software for your precise needs or for an especially fancy piece of functionality. My advice: unless it is a "business critical" operation which you have to have customised for you or unless you can show real benefits from doing it - wait. Hold off. Don't do it just yet.

(By the way: by "customising", I mean more than merely "configuring" the database - I mean that customising would mean the supplier would need to make bespoke changes for you, write code which would change it from the norm etc. See my "Keeping it Vanilla" post for a more detailed discussion/definition).

Why? Because, as I said above, this is a time when you are (understandably!) excited about the new system, but it is also a time when you may therefore decide to request functionality which isn't really going to add that much value but which may add significant financial investment… Yet at the same time, it is quite likely that you don't yet know the new system you are implementing, at least not at any great detail, and even if your supplier does (well, we hope they do!), then conversely they may not fully understand your needs. (And of course they may be quite happy to accept a few extra pounds/dollars for that extra piece of custom work…)

Instead, add such ideas to a list, learn more about what the software can do and then, once you really know the software, then you can decide if you really want to invest in that extra, whizzy functionality. Because what you might find is that either that function is not quite so important as was first envisaged, and/or you can achieve 80% of what you wanted just by configuring the database yourselves for free. Plus, you will keep the initial implementation simpler, quicker and cheaper, with less risk and you can approach it in a far more structured way. And you can then move on to your Development Stage of the project and really start to add value and benefits where you really now know what you want.

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

 

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.

Is There Any Need to Develop Bespoke Database Applications anymore?

I was interested to see a recent article on ComputerWorld which detailed how the charity, Freedom from Torture has developed a bespoke case management system because they couldn't find an off-the-shelf system which was suitable for their needs.

Now, I of course have no knowledge of the charity's requirements, so it might well be the case that they did need to develop their own system and it sounds as though they have ended up with a good solution for their needs.

But what is interesting is that, for database applications such as this, the bespoke approach is becoming a rare occurrence these days, primarily because of the flexibility, adaptability and affordability of many "generic" CRM systems which are now available to charities and NFPs.

The rise of the CRM system
I have discussed before on this blog how systems such as Salesforce, Microsoft CRM Dynamics, SugarCRM, civiCRM and others are all great solutions which, although they have their roots in sales and contact management from years ago, have progressed way beyond that now and have been enthusiastically embraced by the nonprofit sector worldwide (and by other vertical sectors too) because they can be adapted to so many requirements which are essentially based around contact management - but of course can provide so much more around that, be it fundraising and income, membership, volunteer management, case management and so on.

This is the case for large NFPs such as Barnardo's and the Alzheimers Society, who are both implementing Salesforce for their 'cause related' database, and there are many, many small charities who are using all these systems for all sorts of applications and requirements. And just recently, I was talking with a senior manager of another large UK charity who are considering using one of the above CRM systems for their entire volunteer management because it will be so much easier to do than write one from scratch - and that will support part of their core work.

There are also many examples of companies who have developed 'templates' for various charity requirements on these CRM systems - and I know of at least two companies (HomelessLink and Vera Solutions) who have developed case management systems based on the Salesforce platform.

The Probable Decline of Bespoke Database Developments...
So whilst I appreciate that bespoke database solutions are not going to disappear overnight, and there may be good reasons and occasions when they could be right to use - and I am sure that there will still be thousands of Microsoft Access implementations in the sector for years to come - I would still almost always at least consider first if a charity could use a generic CRM system as the benefits are so great: speed of implementation, flexibility, third-party apps and tools, reporting, email integration are just a few which immediately spring to mind; plus, importantly, a better chance of future-proofing (and future enhancements) and, of course the bottom line, they can very well be more cost-effective.

Why it is a Bad Idea to have “Phase 2” of a CRM Implementation (andPhase 3, 4, 5…)

When you implement a new fundraising database or CRM system, you will always have requirements and wishes which you will want to implement after your initial go-live – often, many such wishes!
Traditionally, this has been managed by breaking down a project into “Phases”. Phase 1 is the initial implementation, i.e. the build-up to your “go-live” with the new database, and then you plan to implement Phase 2, Phase 3 and so on.

But I think this is a bad idea and we should look at alternative approaches.

The problem with Phase 2, 3 etc
Why? Because the problem with this is that, so often, Phase 2 and other subsequent phases just don’t happen. Or if they do, then they are either nothing like they were originally envisaged, they don't achieve the benefits that were planned or they are cut right back so much that they are barely recognisable as a "Phase" at all.

And why does that happen? Because during the initial implementation, there is all the drive, adrenalin and organisation about the lead-up to go-live and all the impetus which goes with that - and then (understandably) after that has happened, there is a huge sigh of relief and people just get on with what are/were doing. And what was for that first part of the project, quite possibly, a significant project team with senior management support and understanding, is no longer a recognised unit - but whoever is left is still, somehow expected to get on with Phase 2.

And then there is the minor inconvenience of a budget. Whereas most (well ... some) organisations recognise the need to get the database up and running and therefore allocate an appropriate budget for that project, once that has happened, the concept of allocating yet more, possibly still quite significant money towards a Phase 2 (and maybe Phase 3, 4…) is harder to swallow.

It is also quite feasible that, once you have gone live with your new database, that the things you originally thought were important for Phase 2, are now no longer the priority. But you have designed and planned (and budgeted) for the implementation in that way.

Breaking down a Project is Good
One thing I should clarify is that I am not suggesting that the concept of breaking down a project into smaller bite-sized chunks is a bad idea – it isn’t. It’s a good idea. You can’t and shouldn’t implement everything you want on day one in "Phase 1", for so many reasons (e.g. manageability, cost flow, learning what the software can really do, dependencies, timescales, future changes etc).

And therefore we should be planning to go-live with a defined scope; and other functionality and benefits should of course be left for after that.

The Alternative: On-Going Development
A better idea than Phase 2 etc is to create a “road-map” for “On-going Development”. This means creating a list of all the additional benefits and functions which you already knew about before you started the initial implementation but which were not included in it, and adding to that any requirements which are de-scoped during the initial phase for whatever reason, and any new requirements and wishes which are discovered during that phase.

Thus, you will have a list which you can then prioritise into a road-map and plan to start to develop and implement from now on.

The beauty of this is that you can allocate priorities of desire, benefits, costs, timescales, resource requirements, complexity, risk etc and thus agree which things should be developed first and which should be left til later.

And if another new requirement comes along after a few weeks/months, then you can slot that into the road-map depending on its benefit, urgency, resource requirements etc – and in comparison to all the other things on your list. If it is more important then something else will have to give way. But you won't have to "wait for the end of Phase 2" or stop and then re-start Phase 2 later. (Phase 2a, 2b anyone?) You can also adjust the road-map if, say, your software supplier brings out new features or modules which can replace or complement your planned developments.

Some readers may recognise this as form of Agile Development, and whilst it has similarities, I’m not suggesting that you need to follow an Agile format (i.e. sprints, scrums etc). But the basis of the benefits of this approach and Agile are indeed similar.

The need for Enlightened and Involved Senior Management
Of course, you’ll still need a budget and you will still need x people to do this. And you will be asking for a budget for which you can't necessarily say up-front will bring Specific Benefit A or Function B. So it needs the support of an SMT who are willing to trust whoever is in charge of this (see below). But the good thing is that you will be using your budget and resources in the best, most appropriate and most efficient way for your organisation as it stands at any one moment – rather than keeping to some Phased plan which you came up with ages ago and which you feel bound to keep to because that was someone’s plan.

One way in which you can manage all this is to create a Database Development Team which can meet, say, quarterly and discuss the road-map and determine the priorities for the next quarter/year as appropriate. And if you include in this team the Business and the IT team (i.e. fundraising/finance staff etc and database/IT staff) then everyone will be able to make their point about what is needed, what the benefits are, the time and resources which will be needed and so on.

Different ways you can implement generic CRM systems for fundraising

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

The new generic CRM systems are introducing new ways of implementing fundraising databases for the charity and not-for-profit sector.

With ‘dedicated fundraising databases’ you pretty much have a standard approach to implementation: because they are proprietary systems, you will almost always use the software supplier who designed and wrote the database to help you implement the database. You may do this to different degrees, depending on requirements, complexity of the project, the supplier’s approach, your experience and so on, but you would still do it with them.

But with the generic CRM systems, there are three broad ways in which you could approach an implementation. This is because the system itself is written by one company (i.e. Salesforce, Microsoft etc) and although you can buy them directly from these companies, they are also sold and implemented by third-party resellers. Which gives us the following options:

Buy vanilla and do all the work in-house
i.e. go online, pay for a hosted solution of the ‘out of the box’ - vanilla - system with x licenses and do all your development yourselves.

Benefits

• You are not reliant on a supplier
• It is a flexible approach: you can do it as you want to, do the changes as you go along; good for Agile development?
• You might have a dedicated developer for your needs
• The cost could be good…
• You can integrate any third party app you want
• You will have no issues of Intellectual Property (IP) in terms of development or with future changes (i.e. compared to the IP points detailed below)

Downsides

• You may be re-inventing the wheel
• No input from suppliers or, through their experience of developing other systems, other charities/NFPs; and maybe less experience of using Salesforce/MS CRM etc itself? And not just in the initial implementation, but on-going over the subsequent months/years too.
• You need a dedicated developer(s) with these skills
• What happens if your developer leaves half way through the development? 
• How will you be supported after you go-live? How will you maintain the system if/when the developer leaves?
• Cost could be high compared to buying a template or even getting a supplier to help?
• It may well take longer to implement
• You need to know of or find out about appropriate third party apps

Buy vanilla and get a company to configure/bespoke for you
This has probably been the most common approach over the last few years for UK charities with significant-sized projects – to use a third-party company to do the development for you.

Benefits

• Such companies can be flexible: they can get the system to (hopefully) do what you want
• All their experience (a) of developing fundraising systems on this platform, and (b) of the platform itself and appropriate third party apps
• Not reliant on an in-house individual and any vagaries of such employment
• Cost might be better than doing it in-house? Will depend on scope.
• On-going support
• Should/could be quicker than in-house development?

Downsides

• Still potentially re-inventing the wheel to a degree
• Any IP issues?
• Reliant on the supplier’s interpretation of your needs, their proficiency, business analysis skills – you will need to manage these risks
• Reliant on the supplier’s knowledge of fundraising
• They may have preferences for third party apps which aren’t best for you?
• Unless you have a supplier who you keep as a support company, you will need to keep on top of future developments and enhancements on the system.

Buy a templated version
There are now ‘templated’ versions of systems such as Salesforce and MS CRM which have been designed by third party resellers. These companies have taken the original CRM system and created a charity/fundraising version which you can buy on top of the CRM system itself.

Benefits

• Should be far less need to re-invent the wheel
• Their experience of fundraising requirements, the platform and input from other charities who have already implemented it
• With other charities also using it, you should get more proactive changes in months/years to come (i.e. a la dedicated Fundraising packages)
• Could well be cheaper for basic requirements (but see below too)
• Should be lower risk because you are seeing more of what you are getting up-front
• The approach should prove to you whether the company are (or are not) so fundraising-savvy

Downsides

• You will be more tied to their version than if you developed the system from scratch - but that is of course what you are buying! (It would obviously be useful to compare different templated versions if you can, if you have time/resources and if that is appropriate for you).
• You will probably still need bespoke work on top of the template, so is there a point when it becomes not worth buying the template?
• You need to consider IP issues far more carefully. i.e. if you are buying a company’s template, then can you make your own bespoke changes to that? (Unlikely). And if in later years you decide not to use their services, can you still continue to use their template?
• On-going costs can add-up if you have to pay annual costs for the template version plus any third-party apps you use.
• Still reliant on the supplier’s interpretation of your needs, their skills, business analysis skills – although hopefully less so than building from vanilla. And you can see what they have done so far so you will get a good feel as to whether you think they are good enough or appropriate for your requirements.
• They may have preferences for third party apps which aren’t best for you? And if these are more tightly built into their version, then it may (?) be harder to get others?

“Hybrid options”
There may also be ways you can combine some of the above. e.g. It would be quite viable to get a supplier to help develop the system for you in the first place but then employ an in-house developer for subsequent support and enhancements. But be aware of any IP/support issues for something like this.

The Need for Business Knowledge - i.e. Fundraising and Technology
One specific thing which I think is necessary when implementing generic CRM systems for fundraising and membership is the (preferably) in-house knowledge of the business - i.e. fundraising - and how it fits with technology. Whereas with a dedicated fundraising database, you have the functionality and some of the approach defined for you by the package and supplier, by defintion of using a generic system, you will need to have far more input into the requirements and development of the solution.

And this means having someone with experience of doing that before so that they know what can be done and what you can benefit from. It is like Donald Rumsfeld's famous quote about the known knowns and known unknowns etc. i.e. If you don't know what you can do, then how can you be sure you aren't missing out on some benefits? A dedicated fundraising database gives you some reassurance over this, but a generic CRM system may not.

My advice: have an in-house person, or bring in an in-house contractor, to be involved with and help manage any significant generic CRM implementation.

Part 1: The Impact of the New CRM Systems
On the Fundraising Database Market

 

Part 3: CRM Systems vs Fundraising Databases -
How do Costs Compare?

9 Guaranteed Ways to Improve the Use of Your Database : Part 2

This is the second part of my blog on guaranteed (really!) ways to improve the use of your database. (But please do refer to my first part for a couple of caveats on the Ease, Time and Cost points...)

6. Instigate a structured training (and learning) culture

One of the most common complaints from end-users of CRM systems is that they have not received sufficient training. The training may have come from the person who’s job they were replacing, it may have come from someone else entirely who knows a bit about the system, it may come from someone who has been at the charity for years and is still following processes which are way out of date. Or they may have just been given an old, dog-eared collection of papers and told that is the user manual – or they may not have had any training at all!

If you want your database to be better then you need people to use it as it is intended. And therefore you need to train them. Properly. By people who know what the database should be doing, who know what the latest processes are, who have the time to train someone, who are happy and comfortable training someone - and, of course, training someone who has the time and inclination to learn. Being trained on your organisation’s database should be part of someone’s induction plan when they join your charity.

I also distinguish between a 'training' and a 'learning' culture: individuals should be encouraged to learn more about the system(s) they are using. This isn’t necessarily easy! Why should they bother learning something or asking more about something or wanting to improve something if it doesn’t help them with their job? So make it so that such practise does help them with their job. If they can’t do something on the database then encourage them not to remain quiet but to tell someone. If they have a good idea then get them to tell someone. The more people learn about what is possible on a database then the more they, you and the organisation will get out of it.

Ease: No technical skills, but needs Senior Management support

Time: On-going

Cost: Free

7. Create reports (and dashboards) your users and managers really want

If you really want to improve the use of your database, then you need to give users and managers information which they really want. So ask them what information they want, ask them what would really help them in their every-day role and with their strategic role, ask them what is most important to them and what they have always wanted to know! You might want to “manage expectations” around this by explaining that you might not give them what they want tomorrow... but you will try! You might also find that they can’t get such reports because no-one is collecting the data they want. So they can then help you rectify that.

Then create reports which they can use. And dashboards – managers love dashboards.

Ease: Needs technical skills

Time: Each report might take from a day to many days!

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

8. Create a Business Analyst role

This is one of the best ways you can get more out of your data and database, but it is also one of the more expensive. Human Resources always is. But what a Business Analyst (BA) will bring you to your organisation, if you don’t akready have one, might change and improve the way you do things so that they will more than pay back their salary.

Because what a good BA can do is go out to the users and discuss their needs, ask the managers what information they want, examine the procedures and processes you have, work on strategic documents with your staff, analyse data, analyse the database, produce options for change, make recommendations and help implement. They can act as the “bridge” between your database team and your users.

I realise this might sound like some “impossible creature” to some people, but really, they can be one of the most important roles in any organisation. To have someone who understands data and databases and what they can and can’t do, but can talk to your users and understand their business is gold-dust. If you find someone who can do this for you, hang on to them!

I should also say that although I use the term "Business Analyst" and define it here as a specific role, if you have someone who can do this sort of work even if they are formally called the "Database Manager" or any other similar position, then that is just as valuable. It's the skills and process which are important, not the job title per se.

Ease: Can be quite difficult to find someone good

Time: Permanent role

Cost: Expensive, as in you need a full-time employee on a reasonable salary

9. Get rid of any Data Ownership hang-ups

I’ve blogged about this before, so to summarise here:

Many charities are now moving away from "data silos" and the concept of "owning one's records". Which is great news and about time. So the next time one of your users/colleagues/staff says to you, "I don’t want my contacts to be stored on a central database because I don't want anyone else to be able to contact them…" then this is the response I recommend you give them:

The fundamental problem with this is that if they don't store their contacts on the central database (and instead, for example, keep them stored in Excel) then, in actual fact, it will be impossible for them to stop anyone else contacting them - assuming that such contacts have - or will have - other relationships with your organisation which are already stored on the central database. For example, if your user is the events manager, then if any of their event registrants are also donors, volunteers, prospects, on other mailing lists etc and as such they are already stored on the central database, then how can the events manager stop them being mailed? No-one using the central database will know that they are also on the separate events spreadsheet. Moreover, they will probably need to be contacted sometimes by other users anyway.

And anyway, it isn’t “my data”, it is the charity’s data. Start using it for the holistic benefit of the charity.

Ease: In theory easy, but you get stubborn individuals!

Time: Instant to instigate, may take time for everyone to buy-in

Cost: Free

I hope you find all these suggestions useful. They really will improve your database if you put them into practise in a structured and considered way.

And if you have any other suggestions then by all means leave a comment below.

9 Guaranteed Ways to Improve the Use of Your Database

Each of the following processes will improve the use of your database - really! Some are simpler than others, some are free and some definitely require investment, some require technical skills and some just need a new business approach. But they are guaranteed to bring you benefits if you don't already follow such practises or you haven't implemented such functionality. And you can quote me on that!

I have also tried to indicate for each one how easy it is, how long it would take and how much it would cost. Please bear in mind these will of course vary depending on your specific requirements, your database, your in-house skills and so on. So don't quote me on those figures quite so much...

I have split the blog into 2 posts, so ideas 6-9 will follow in a separate posting.


1. Clean your data (and do a data audit)

It doesn’t matter if you have the best database software in the world – if your data is rubbish then you won’t be able to use the database efficiently. End of story. Because if you have records without key data, incomplete addresses, blank fields where they shouldn’t be blank, duplicate records, inconsistent data in the same field, different use of the same field, if you can’t store specific data items which your users need, unreliable data and so on and so on, then how can your users trust the database, how can they produce reports or do queries or segment the system properly or base decisions on correct data, plan their strategies and do their every day work.

So clean your data. Ideally, do a data audit: create a report which shows the different areas of your database, what fields you have, the type of data, record counts, counts on data items in key fields, data integrity issues and so on. Then you can plan your data cleaning exercise properly and in a structured way.

Ease: Not too difficult

Time: Audit: 1-2 weeks. Data Clean: several weeks upwards

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

2. Add data integrity rules

Following on from (1), we need to keep our data clean and one of the best ways to do that is at the point of data entry, and one of the best ways to help enforce good practise for data entry is to implement data integrity rules into the database. So, for example:

• Ensure that a drop-down table (a.k.a. look-up or reference table) is used on fields which have a set or finite number of options within their data set. E.g. Counties, ethnicity, appeal code, type of interaction. (And don’t let end-users add their own codes to such tables!)
• Make fields “Required” where they must have data recorded in them (e.g. an individual’s last name, a specific code). But bear in mind that if you do that, then there must be an option for all possibilities. E.g. if you make Post Code required then what does a user add if they really don’t know a contact’s post code?
• Use defaults. For fields where there can be a default, add one. Users can over-write if appropriate.
• Manage rules on date fields; e.g. don’t let dates get added which are after today’s date where this shouldn’t happen; e.g. date of birth.
• Use calculated fields. e.g. Automatically calculate age based on date of birth, as opposed to asking a user to key that data.
• Automatically populate fields based on other fields: e.g. gender based on title (where possible), cost centre based on fund designation.
• Properise fields where possible and appropriate; i.e. with an initial capital letter. e.g. First Name.

And run “data integrity checks” against your database at regular periods. So where it isn’t possible to create a simple rule on a specific field, create a query/report whereby you can at least produce lists of any data anomalies. For example, appeal codes which shouldn’t be on specific record types, individuals marked as deceased who are still giving donations, UK counties on a record with a foreign country.

Ease: Often needs technical skills

Time:  From a few days to on-going

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

3. Don't allow people to use any spreadsheets instead of your database

If you have a database which your staff should be using then don’t allow them to use spreadsheets instead. As soon as the first, external spreadsheet is created, then the data integrity between the two will be lost. Data updates won’t be done, your other users won’t know about specific information now stored on that spreadsheet, you can’t keep tabs of communications with the people on the spreadsheet, there is no security on the spreadsheets etc.

Keep all data which should be on your database on your database. You may need to get a central message from senior management to help you enforce this but it will all be worthwhile.

Ease: Easy to start! (Can be harder to enforce...)

Time:  Immediate... but then on-goin

Cost: Free

4. Automate what isn't automated

This will always help your database, whether it is for the database team or the end-users. If you can automate something then it will be quicker, more efficient, more accurate, more timely and really optimise what a database is for.

For example: Gift aid claims, reports, mailings, acknowledgement letters, exports to fulfillment houses, importing data from fulfillment houses, extracting data for your finance system.

Ease: Need technical skills

Time: Depends on task but each will probably take time

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

5. Integrate it with your web site

If you take online donations, accept online event registrations, let people sign-for newsletters or if you would like to let your supporters update their own address and contact details, opt-in/out to specific communications etc, then you need to update your fundraising/CRM database in one way or another with such data. If you do it manually at the moment then the time and effort is likely to be pretty high.

Integrating your database with your web site so that this can be automated in one way or another will bring great benefits. But it isn’t the simplest thing to do from a technical point of view, nor the cheapest. And you’ll need input and co-operation between different teams so it may not be the easiest in that way either and may take some time.

But if you can automate such integration then you will save so much time and effort internally and add some great data capture, so that the benefits you can get from doing so may well outweigh the cost.

Ease: Often difficult

Time: Allow several months from start to finish

Cost: Potentially high

In the next post, I will consider training, reporting and the benefits you can get from a business analyst.

Can I Use Microsoft Access for my Fundraising Database?

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

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

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

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

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

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.