The Challenge of Secure Communication Records in a Single, Shared database

 

Most database systems can record contact/communication history with your contacts, prospects, donors, benefactors et al. i.e. letters/emails, meetings, phone calls, services used etc. But what if your organisation and security needs mean that only some of your users should only see some such communication records?

Let me give 2 examples:

• If John Smith is a major donor, then you will want your major donor fundraisers to be able to see the communication record of the important meeting you had with John last week; but what if the detail in that meeting was so sensitive that you don't want fundraisers in other teams to be able to see it?
• Or, what if you are using your database for benefactors as well as donors, and what if Jane Smith is both a donor and a benefactor - thus, if you add a communication about Jane which only your charity's "Services' users" should be able to see, maybe a Counselling Session she attended, then how do you stop the fundraisers from seeing the fact she attended that session?

Now, some database systems offer functionality around security so that they can completely hide such communications from specific users. However, if you completely hide all such communications, then what about the following case: a fundraiser opens Jane's record and because he can't see that Jane had 3 communications in the last month with your charity's service users, he thus has an incomplete picture of Jane's interaction with you and might therefore approach Jane with insufficient or inappropriate knowledge.

And if they can't see the total communication history, and you are basing any appeal letters, event invites on recent or total communications made, then such analysis may be skewed.

So, how do we show all database users that some sort of contact/communication was made with a donor/contact, but only show relevant users the details of such communication?

It isn't necessarily as easy as it might first sound. Many systems have "one line" (summary) overviews on a Communication History form showing all communications at a 'top level', and then you drill-down (double-click) into each instance to see the details of a particular communication made. So at the most basic level, you want to stop some users from being able to drill-down into the separate communications where they are of Type X etc. This might be possible in some databases.

But taking this a step further: if you, say, have the communication "subject" or communication "type" on that one-line overview, even those few words might tell the "wrong" users too much about that communication - especially in the example of where donors and benefactors are all held on the same database; in that instance, even a subject such as "Counselling Session" might be considered inappropriate for fundraisers to see.

So, ideally, you want one user to see a view where the subject/type is the full details, but another user should only see that "some form" of communication was made but not the details. That can be trickier than it sounds for database developers.

So I throw this question out to you all: if you use a database where this problem has arisen and has been resolved, then do let me know how in the comments below. Or if you are a database supplier who has got around this problem, tell us how in the comments below. Or if you have ideas/thoughts on any of this, or further examples of similar issues, again, add them below. I'd love to hear more.

Should We Be Buying Fundraising Software Anymore?

The case for not using fundraising software per se...
It is highly likely that on your fundraising database, you will have donors or prospects who also have at least one other "type" of connection with your organisation. e.g. they may have bought products of some sort from you, they could be a ticket buyer, they might be a benefactor, a trustee, a volunteer, a subscriber/user of your website and so on. In which case, you may also hold their details on another database as well.

So if that's the case, then should we really be buying fundraising software anymore or should we be buying an organisation-wide system which can manage all this information?

Because the problems with having "isolated" fundraising databases include the following:

• They only store fundraising-related information about your donors/prospects and so you don't know about their wider engagement with your charity. In which case you don't have the full picture which means you might not be getting the most out of them - or helping them as best they want to be helped - or you might be communicating with them inappropriately.
• You might be writing to or contacting them at the same time as someone else in your organisation is also doing so - you can't manage an organisation-wide communication strategy or central contact management if you don’t know and can't control what other teams in your charity are doing.
• Having isolated systems (fundraising and other) engenders the "But it's my data…" paradox and problem. (Why a "paradox"? Read my previous blog post on what to say when someone says "It's my data"...)
• It is harder to do organisation-wide data analysis and marketing.
• And if you do want to "integrate" systems - make different systems "talk to each other" - then sadly that really isn't as easy or as cheap as you might hope or be lead to believe. Even integrating two databases is tough, let alone multiple systems.

On the other hand...
But if it is that simple, that obvious, then why is there still such a market for fundraising software and why don't all charities start to use a single, centralised database. Unfortunately, it isn't that simple.

• Specialist functionality: Fundraising needs specialist functionality in their database, from income processing, Gift Aid and managing direct debits, through to relationship management and prospect research. And other areas of your charity will need specialist functionality in their databases too: trading, websites, management of your services/service delivery and so on. And one, central, large database system may not be able to manage all that - or if it can, then can it do so with the same high levels of functionality that 'best of breed' systems can do?
• Data/database/organisation/change management. Having one, large database makes data management and change management a lot more difficult, involved and time-consuming. If you only have fundraisers to think about then any change or new data item only needs to be considered for them. But if you have more teams and users, then it will be far more work when considering and then implementing any such changes. Similarly: where would the database management reside for a charity-wide system? It probably isn't appropriate for fundraising to manage such a broad database and, often, IT aren't really the best people to do this sort of thing. You could have a dedicated "CRM" department but that's probably only cost-effective and practical in larger charities.
• Budgets/Organisation policies. Many charities have budgets specifically for each particular department so if you want to buy an organisation-wide system then that needs to be addressed.
• It's hard work! Organisation-wide systems take a lot of work, time, effort, resources, discussion, buy-in and money. And often present a riskier proposition.
• They aren't always appropriate. For some charities, it might be appropriate to completely separate the departments and functions and thus the databases. I think this is getting less common but it could be the case. Of course, even if it is right for one organisation, that doesn't necessarily make it right for another. Organisation size can play a part - smaller charities might actually find it easier to create a single, central database than larger NFPs.

But still - will we buying Fundraising Software? Should we...?
Having said all that, none of the above are necessarily reasons not to consider an organisation-wide database, they just need to be understood and planned for. And if it is the right route for your organisation and you can plan for and implement it successfully then it could well offer you significant benefits.

It's also true that some of the 'traditional' fundraising database suppliers are getting smarter and are offering systems which can manage more (much more in some cases) than just fundraising functionality. That may well be an option for some charities.

But in the meantime, whilst we are still working around some of the issues listed above, we will still be buying fundraising software at least for now.

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.

Keeping Changes of Database Supplier in Perspective

 

If you are considering the procurement of a new fundraising database package and you talk to another charity about what they use, then you may well find that they have migrated from one "recognised" fundraising package supplier to another. e.g. to or from companies such as ASI, Blackbaud, IRIS, ThankQ and so on. Or indeed, if you peruse internet discussion boards, then to and from CRM systems such as Microsoft CRM, Salesforce and SugarCRM. As such, you might therefore wonder why someone is no longer using the very package which you were considering buying.

My message is: don't necessarily worry, find out more about each such situation and don't lose sight of the more important factors in any database implementation: the data, the people and your business processes.

Of course, if you find patterns of desertion from one system then that could be an issue (and there are indeed one or two suppliers who I would be more concerned about if you told me you were buying their software now), and if you do find no-one who can give you good feedback about supplier X then that should at least make you think twice.

Equally, there could be good reasons for a charity to move to a new supplier: their 'old' database might not be appropriate for them anymore (e.g. they could have grown out of it, changed technology platform); in-house skill-sets may have changed; the supplier's costs might have escalated significantly; the supplier may have been selling, or now be selling multiple systems and therefore have dropped support for one database. Or the 'old' supplier might not be providing perceived value anymore, might not be releasing new versions, might have cut-back severely on support.

But all too often a new system is purchased for reasons not truly central to the database software itself: a new senior manager might arrive at a charity and prefer database X; there could be loss of faith in the 'old' database when in actual fact it was more down to the poor data, lack of training, lack of investment, a great database manager leaving and not being replaced etc etc; there could be a misunderstanding or lack of knowledge about the capabilities of the old database; an out-of-date version might be being used; or a charity's IT infrastructure might be so poor that the old database is running so slowly that any modern database would struggle…

And with the more successful database suppliers, if even a small percentage of their clients are unhappy, then that will be more visible to the market compared to a smaller supplier who might only have one or two users jump ship over time.

So consider carefully if you hear about a charity moving between fundraising systems and you are thinking about buying the database which that charity just dropped. Try to understand why that charity replaced their old system, who was involved with that decision, how long ago - what they learned from the process. Talk to as many such other charities as you can and get a broader picture. And remember that whatever system you buy, the software is still only one part of the success of that new database.

How long does it take to implement a new database?

... and the Influence of Project Scope

 

One of the hardest things about implementing a new CRM system or fundraising database is going at the right pace: too fast and you may rush things, forget something, not do enough testing etc; but too slow and you can lose impetus and enthusiasm – “sorry, why are we doing this project, again?” It’s a tough call.

Historically, I’ve found that charities start such projects with too tight a timescale and don’t leave themselves enough time to get it right, but then often relax such time constraints too much so that they leave themselves in danger of losing all the goodwill and excitement which they had when the project commenced. (Although some organisations do do the opposite!)

And by “implementing a new system”, I am specifically referring to what we can loosely call “Phase 1” or “going live”, which means starting to use the new database in a live environment for the first time and stopping the use of any old database. Thereafter, of course, after we “go live” there could well be more “phases” (although more about that below...).

Perhaps unsurprisingly, one of the things we can do to help us understand how long it should take is to review and understand the project scope, so here’s a few things to consider which might help you get this right. (NB: I'm aware there are clearly other factors which influence timescales, from the type of software to resource availability and  budget, but scope is still one of the most central points to consider).

Go Back to Your Business Case for the Scope

You do need to consider what you said you would achieve in your Business Case. If there are some things in that which you now feel you can’t do in an “acceptable” timescale, then you might need to get any changes approved, but you need to be at least laying the foundations for why you initially decided that a new system was required.

What you must do in Phase 1

The new system needs to deliver some tangible benefits and manage key and critical business requirements. This doesn’t mean implementing all your wishes on day 1, and it doesn’t even necessarily mean replicating everything which you can do now in your existing database - but you need to ensure that it can: meet any fundamental operational requirements (e.g. processing donations, producing acknowledgement letters, recording basic information etc); manage any business critical processes (e.g. making direct debit claims, providing mailing files/letters for appeals); and (almost certainly) ensure that it can do regular, automated tasks such as importing third-party data feeds, produce Gift Aid R68 claims etc. I say almost certainly because, for example, if you can’t do a Gift Aid claim immediately, then you can still do that x weeks/months later and still claim the same gift aid (assuming it isn’t the end of the financial year and thus you miss a 4 year back-claim).

Enabling Reporting in Phase 1

If you don’t provide reports then people will very quickly question the benefit of the new system. You can of course technically go-live without producing reports, but if you do then so much of the benefits from any database will be lost. It may be that you can’t immediately produce all reports on your wish-list, but that’s okay as long as you plan their delivery over the weeks/months to come.

Keeping it Vanilla

I’ve written previously about the benefits of keeping your initial implementation as “vanilla” as possible and not being drawn into designing complicated customisations which will take time, cost money and increase risk. This will help maintain a useful, structured timescale.

Planning Post-Go-Live Development

If you do cut-back on the scope of the project to get an earlier go-live date, then make sure you plan and communicate when you are going to implement those things which were left out of “Phase 1”. And my recommendation is not to do this as “Phase 2”, “Phase 3” etc, but to move into an “On-going Development” phase, whereby the other items are planned for in this way.

Try to include some Quick-Wins which will Inspire and Excite

If you can do, include a few really inspiring things which will get people excited about using the new database. What this is will of course depend on what your organisation has had before, your users and their expectations! It might be something as simple as introducing mail-merges which do conditional merges and produce different letters; it might be mapping your donors on a Google map; or it might be automating something which has previously taken a long time to do manually.

Don't tie the project to "fake dates"

So often it is the case that charities say they must go live by date X. Often because someone senior has said that this must happen - but without considering any of the above, or other issues, and without really understanding what is involved. If you originally believed you had a 9 month project, but for whatever reason, you start 2 months late, then why should it suddenly be viable to make it a 7 month project?

Similarly, be aware of - but be careful of - dates in the year for when you must do it by; e.g. end of financial year, before a large campaign etc. There may well be good reasons for considering such dates as part of the project plan, and if you can do and if it is correct to work them into the project then that's fine. But if they constrict the project too much then don't let them over-rule everything else.

Understand availability and restrictions on your staff's time

Very often a supplier can work more quickly than the client, and charities often find that the amount of work needed to implement a CRM system is far more than they expected. So don't under-estimate the amount of work it will take your key users especially, and either allow them time to do their Business As Usual as well, or back-fill (some of) their work.

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.