Initial Thoughts on ThankQ's Acquisition by The Access Group

The Access Group (Access) have just announced that they have acquired fundraising database supplier, ThankQ. These are my initial thoughts on what this means to ThankQ users and to the UK NFP sector as a whole.

• Access' have existing NFP solutions which are already used by 500+ UK organisations but they do not have another "CRM" system which they sell to charities (although they do sell GoldMine, but that has fewer applications for NFPs). So at first sight, ThankQ could fit well into their portfolio. And because they don't have an existing fundraising database system, they won't be migrating ThankQ users to another system they already sell. So, that would seem to suggest they see it as a system they will continue to support. Which should be good news for ThankQ users.
• One of the potential issues which ThankQ did have as a company was that, despite their sales success, they were still a comparatively small company with lower staff numbers and a much lower turnover than their key competitors such as Blackbaud, IRIS et al (let alone Salesforce and Microsoft!). So they didn't have the same money or resources to develop their software as per their larger competitors. So, if Access are serious about incorporating ThankQ as a system which they intend to continue to promote to the NFP sector, then it might be that they could invest more to a larger R&D budget to the software. In which case, that could really help ThankQ and its user-base.
• Of course, one of ThankQ's main plaudits as a company was its flexibility and approach, which it was able to follow as a small, independent organisation. It will be of high interest to ThankQ's existing and new customers as to how that now pans out. I wouldn't see any reason as to why Access would necessarily change the fundamentals of that, but it would be foolhardy to think that they wouldn’t want to introduce some of their own methodology and culture to their new group member. Like any acquisition, we shall have to see what is good or bad about that.

But how does this impact the UK NFP sector as a whole in terms of fundraising/CRM database suppliers?
ThankQ are (were) certainly one of the more successful, completely independent companies who purely sold just one fundraising database, so it didn't take a futurologist to predict an acquisition could eventually happen. And of course what we have seen over recent years are the larger players in the market buying their competitors; Blackbaud, IRIS and ASI being the obvious examples as well as others like TSG and Miller Technology. Some products have remained within these companies' portfolio but others have not, or have not had the same commitment to their on-going development. Which in some instances has meant less choice for charities.

So it has to be said (unless there is some other reason for Access' acquisition of ThankQ, or unless Access are now about to go on a spending spree and buy other similar systems - and I have no reason to believe that either of those issues is the case) that this acquisition should be no bad thing for the sector. A good database should hopefully remain a good database and a strong competitor but possibly now with more investment. I hope I'm right.

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.

What is the best way to invest additional budget in a CRM implementation?

I have this little dream that a charity phones me up one day and says to me, Ivan, we have some spare money we want to invest in our CRM implementation - where do you suggest we spend it? Unfortunately, before I can say, "Me! Me!", I of course wake up.

But it has made me think: if someone was to ask me, if we wanted to spend more money somewhere on our CRM project, then where should we spend it - and assuming that I am wearing my incredibly self-righteous hat so that I don't of course say me - then what would my answer be? I'm also assuming for the purpose of this hypothesis that they already have an existing budget which is "satisfactory" and certainly enough so that the project could at least be completed "satisfactorily". Thus, any extra money would be a complete bonus to add real extra value.

So, what would I do with such a windfall?

What I wouldn't spend it on
Interestingly, when I challenged myself to answer this, I found it harder than I thought I would. So let me start off by saying what I wouldn't spend it on.

• Extra software licenses. I don't think you need more licenses at the start of an implementation and, ironically, if you did buy more licenses then it would probably mean the need for an even larger budget to cope with the extra demands.
• Better Hardware. I don't think more powerful hardware will add as much extra value as other places.
• Data cleaning. Again, important, but not as important as other points.
• More training. More controversial perhaps, but, assuming we would be spending it on more training from the database supplier, I think extra training could be delivered in-house by the charity's own trained staff with more time... see below.
• Additional project management. As I am often a PM, this might be surprising, but there is a limit to how much project management a project needs and anything above that isn't going to provide the same benefits as other things.
• Software customisation. I've written before about how I believe we should keep a new CRM system as "vanilla" as possible, so I don't think spending money on more customisation up-front is the best approach.
• Integration. I was close to including this in the list below in my short-list for consideration. There are great benefits from integrating a new database with, say, another database in your organisation, or your website if it hasn't been linked before, or with an email marketing system. And the only reason I am not suggesting the money should be spent on such budgets in this scenario is because I think, if it wasn't already in scope then it would make the project larger and harder to implement in Phase 1. But if I had more money which I could spend later then, yes, this would be a prime budget to use it on.

What I might spend it on
My short list:

• Consultancy from the Database Supplier - post-live. (I can just hear the CRM suppliers cheering whilst reading this!) One of the key things about implementing a new system is understanding what it can really do for your charity which will provide real, solid benefits, aligning it to your processes, and enabling your staff to understand what the new database can truly manage. And for these reasons, I would consider buying more post-live consultancy time from the supplier. Not more time during the requirements gathering stage etc, but after we go-live when we actually get down to using the darn thing. That's when I think we can get most benefit from such consultancy.
• More resources (people) during the implementation. i.e. most likely, freeing up the time of the existing, key staff who could be involved on the project, but because they often have to consider their Business As Usual, they too frequently cannot dedicate the time to the project which ideally they should. So getting in more resources to do their BAU so they can concentrate their efforts on the project will pay dividends in spades. It will mean they get more involved, earlier, with more understanding of the new system and the charity's systems/processes, will become stronger advocates and supporters of the database and will mean that the whole thing will stand a much better chance of going live successfully.
• Creating reports ready for go-live. This is sadly one of those areas which is often under-budgeted for (and under-scoped) but can provide so much benefit: being able to implement reports as soon as you go-live - being able to uncover and streamline benefits from data and information. Indeed, the difference a new system can make and through reporting and analysis is an immense benefit to have.

My final decision
So if I am offered my extra budget then, weighing up the above options, the area which I believe would give the most extra benefit and value would be spending it on "more resource during the implementation"; or as I said above, probably back-filling existing staff's roles so that they could be freed up to do more work on the project itself.

I think that this would mean so much more to a charity and would not only help the initial implementation, but would provide a far stronger base for future development and on-going use of the new system.

Now over to you...
What would you do? What would spend it on if someone gave you an extra wad of cash to invest in a new database implementation? Answers in the Comments below please!

CRM Gamification - Useful for Charities? Or Just Not Right?

 

I don’t know yet if I think it is cool or whether I really hate the word, but Gamification is one of the latest buzzwords to hit the commercial CRM marketplace, and I’m wondering if it is something which could also be adopted by charities with their CRM technology. There is even one CRM supplier, Zurmo, who provides open source CRM software and their whole business model is based on Gamification. Fascinating.

What is Gamification?

For those who don’t know, Gamification (within this realm) refers to the adoption of using gaming techniques and ideas within business systems. So, for example, within the area of CRM and Sales,  salespeople are encouraged to identify more opportunities, have more meetings, close more sales etc by winning points and gaining more awards the more they do. Commonly this is in the form of ‘badges’ and different levels of badge, league tables, points and so on. i.e. it is not just financial, although in theory the financial rewards will come for the better “Gamers”.

Unfortunately, this is why my initial thoughts are that Gamification might not work in the NFP sector for database usage. After all, fundraisers are not paid commission, they are not “just selling something”, they are not competing internally within their charity and they are hopefully already driven by honourable motives to raise as much money for their organisation as they can anyway. And fundraisers often work together and (hopefully!) do not try to undermine colleagues and just raise a few pounds towards their target from a particular prospect when the charity could better benefit by another fundraiser raising a lot more from that same prospect.

On the other hand, I’m certainly not saying that fundraisers aren’t competitive! I know many who are! So maybe there is a way in which Gamification could be used in charity CRM systems too? (An example of Gamification within the realm of campaigning/the public fundraising for you was recently discussed in The Guardian).

 

User Engagement

One of the key issues for charities is User Engagement/User Adoption of fundraising and CRM systems. As much as we all know how important the database is, and as much as we try to make it user-friendly, quick and easy to use and provide better user interfaces, there are still very few fundraisers who love databases (in the way that that tech folk do!). So could Gamification make users use databases?

Maybe such awards and rewards could be focused differently? Maybe less directly competitive and more recognition-oriented, or even an attempt at fun! Maybe teams could “compete” but not necessarily on financial targets – could there be other goals (KPIs?) we could use? Maybe even something as simple as running reports! Or perhaps volunteers could be encouraged through Gamification more attune to the commercial approach?

I know one organisation who, during their implementation of a new database, introduced an incentive scheme to encourage users to make themselves familiar with the new system: each month for several months, they had a mini-competition/challenge amongst the users whereby staff had to use some aspect of the forthcoming database in order to win a prize. In the early months, this was a simple as getting users to look-up a specific record on the database and email the competition organiser with, say, a donor’s last donation on that record (which of course meant they had to learn and understand the system to find that information), and for that they got a chocolate bar. But by the time they were going live, the challenges were more difficult/involved and the ultimate prize was a day’s leave (just for one person of course!) – something many staff would certainly value.


So I don’t know…

When I first heard about CRM Gamification I was fascinated and desperately wanted to believe charities could use this, but then I thought not. But now I am trying to look more laterally - are there in fact other ways in which we could adopt such processes? Or is the whole approach just wrong in a sector whose very basis could be seen as the antithesis of commercial competitiveness – at least within an organisation.

Any thoughts?

Why a Database Manager is like an Olympic Triathlete (sort of)

 

It's taken me 2 weeks to come up with some sort of link to the Olympics, and, just as it's ending, I've finally done it. So, with my tongue pressed firmly into my cheek... here is why I think a Database Manager is like an Olympic triathlete. Well, sort of...

• Endurance: You think it's difficult to swim a few miles, cycle some more and then run 10k? Then you haven't had to cajole users to actually enter data in your database (consistently) or persuade trustees to cough-up some money for a new system, or keep those data quality checks going not just on day one, but months or years later.

• Giving up one's social life for something you believe in: Triathlete's think they have it tough when they do a bit of training every day, but trust me, until you've done the late shift 3 nights running because there is an urgent mailing which is going out next week (well, probably going out), then you'll know all about commitment to one's cause.

• Training: Yes, well, not exactly the same, but you'll know where I'm going with that.

• Not willing to accept second best: Absolutely. When you're locking horns with your database supplier, or doing the latest fulfillment import or trying to work out just why that little function has stopped working which had been working so well until last Tuesday's upgrade... then you know all about the urge to win.

• Belief in data: Triathletes love data - they track how quick they've run this week, how much time was lost in transition, how their competitors are doing. They might make quite good Database Managers.

• Falling down and getting up again: For one of these groups of people there are going to be times when it's tough - when you don't quite make it the first time and you need to pick yourself up and try again; when everyone says you're stupid for persisting; when you injure a wrist from pressing too hard. But that's the life we accept as Database Managers. I suppose triathletes do something similar.

(I could go on but you'll probably be glad to know I'm not going to.)

Anyone got any other suggestions as to why a Database Manager is like an Olympic triathlete? Enter them in the Comments below.

The Impact of the New CRM Systems for Fundraising Database Solutions: Free eBook

Earlier this year, I wrote a short series of posts about the impact that the New CRM Systems are having on the Fundraising Database Market (i.e. Salesforce, Microsoft CRM Dynamics et al). I have now compiled those posts into a free, downloadable eBook which brings all the information into one easy-to-read document.

You can download a PDF copy from here.

The book covers:

1. An overview on where we are now with such systems;
2. What are the potential benefits of the systems;
3. A guide to the different ways in which you can implement the systems;
4. How do costs and implementation timescales compare with dedicated fundraising databases?
5. What you should specifically consider if you are considering buying such a system.

Learning Lessons from ThankQ in America

A little while ago, fundraising database supplier (and UK company), thankQ started a blog about a new implementation of their software at their first US customer, Scripps College in California. In it, they said they would be "keeping you up to date with everything that’s happening right now (the good and the not so good!) [and would] share the highs and lows." Nice idea but it needed to deliver what it said on the tin.  And with their third blog post just written by their projects director, Kevin Weaver, I'm starting to now think it might be quite an interesting read.

I do like the idea: a supplier being open and publishing their experiences and lessons from a very new environment for them. I guess the question is, Will this prove to be a useful tool to assist their own customers and even other charities with their CRM implementations? And could it inspire other suppliers (or even charities?) to do the same?

Okay, so I realise that thankQ's blog could be considered to be almost as much a PR tool as it is a series of open blog posts, but I don't think that necessarily matters. If thankQ keep to their word (and they are a good company for doing that) and highlight the good, the bad and the ugly then that will show openness and honesty and will be good for helping all charities learn, and will by definition also be a good sales tool as well.

And okay, they will of course want to report on the implementation going well in order to make other charities want to consider buying thankQ, but that's understood. It's similar to asking for references when you buy a new database. Any supplier can of course provide a reference from a satisfied client. But when I was a salesman, one of the best questions I was asked by a prospect was for a reference from a client who used to be unhappy but which we had turned round so they were happy now. It's a powerful thing to show how, if something goes wrong, then what you did to correct it.

Of course there is the question as to whether thankQ might not write about every really bad thing that happens and one could hardly blame them for that. (Although I could well be proved wrong?!) That is, if something really had happens of course! I've no reason to believe it will but it's a rare CRM implementation where everything is just hunky dory...

And in this instance they do have the client to potentially keep them in check, as Scripps College can blog and tweet about the project too. Which is of course the beauty of social media - there's nowhere to hide!

So cudos to thankQ for this approach - I'm watching with interest. I hope that thankQ, and the rest of us as a community, really can get some interesting learnings from the blog and "thankQ's journey".

You can read the whole ThankQ blog at: www.thankq.co.uk/stories/stateside.

Any other suppliers up for a bit of similar blogging?

What I've Written About So Far in 2012: According to Wordle

Just for fun, I plugged all my blog posts I've written so far this year into Wordle, and the above word cloud is what came out.

It's mostly what I would expect although I'm a bit disappointed that words such as 'support', 'costs' and 'processes' are so small - and maybe 'data' and 'people' should be larger. But I'm glad that (apart from my more obvious keywords) that 'suppliers', 'requirements' and 'need' stand out.

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

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

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

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

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

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

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

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

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

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

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

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.

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

 

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

15 Questions Fundraising Managers Should Ask About New CRM Projects

 

Too often, fundraising managers are not close enough to the implementation of a new fundraising database or charity CRM system; sometimes (incorrectly) by the nature of procurement and sometimes (incorrectly) by choice. But for a fundraising system, they are more likely than not going to be the key reason for why it is being implemented, so why wouldn’t they want to get more involved?

So if you are a fundraising manager and there are plans in your organisation for a new fundraising database, then what questions should you ask during the procurement process and before the project kicks-off?

1. How do I know it will meet my requirements? When do you need my input? How will it be documented?
   The most basic of questions. What is the process to capture your requirements and how can you be assured that it will capture all your needs? The latter point may be very difficult but you need to ask. Is all the reliance going to be on you and your team, or is the database/software supplier or a third-party going to be more heavily involved?
2. How will it help my [DM team/Major giving team/etc]?
   Although this goes hand-in-hand with (1) above, there is no harm in asking specifically about how the new system will help your different teams and aspects of fundraising. What are the actual benefits you will get which will have an impact on your fundraising and income?
3. How is the project being managed? What input do you specifically need from me and how often?
   Has the project got a project manager – part-time or dedicated? If not, push for one! And don’t rely on just the supplier being the project manager – that isn’t the same as your organisation having a PM. And will there be a Project Board or steering committee? If so, how will you be involved and when? You need to be involved somehow – at the end of the day, it will be “your” system, so don’t think it will just magically happen without you needing to be involved.
4. What fundraising experience does the software supplier have?
   And not just the supplier as a company, but the staff who will specifically be working on your project. Most “traditional/dedicated” fundraising packages should have staff with plenty of experience, but for the newer, “generic” CRM systems, is that definitely the case? If the answer is “not a lot”, that doesn’t mean you still can’t work with them, but there could well be more dependency on you.
5. Will we need to change our business processes? How will that be decided and when?
   It is highly likely that you will need to at the very least review your business processes. In fact, if the answer to this is “no – you can keep your existing processes”, then this may sound beneficial, but ask yourself, are your existing processes actually the best processes you can have? Why do you have them? Is it because your current fundraising software has forced you into a certain way of working – in which case, why would you necessarily want to carry on with them?
6. How can the software interact with our website? How can we load data from JustGiving/VMG etc?
   This may result in a technical answer so try to get someone to explain (as much as possible) in layman’s terms. At least find out what the options are, the benefits for each option, the different costs, the level of complexity/sophistication and timescales.
7. How will it impact on our other systems and suppliers?
   You are bound to have other software systems which interact with your current database (e.g. PAF software, banking software, Word/Excel etc) and you may well have third-parties who provide you with data files, such as fulfillment houses, data cleaning companies, online websites etc.
8. What training will my team need?
   Ensure you ask this and if in doubt, ask again. Training is often perceived as a double-edged sword by fundraising teams: everyone seems to want it at the start of the project, but when they are later told that they will need 3 days out of the office, this suddenly becomes less attractive/important. Find out, break it down, insist on it, plan for it.
9. What reports/dashboards come as standard with the database software? What skills do we need to create more?
   At the end of the day, if you can’t get the data out of your new system in a meaningful way to show you reports and appropriate information, then why are you using it. Are there any standard reports and dashboards which come with the software, and if so, how flexible and appropriate are they for your needs? And you are bound to want other reports, so who will be creating those? Will you have to rely on the supplier, or can someone in your organisation (your team?) create them?
10. How will testing be done? What input will you require from my team?
    Another thing which everyone knows is essential but somehow gets pushed under the carpet if you are not careful. Find out what the training plan will be and what will be needed from your team and when. How will they be supported. And do you have any “business critical” processes which you will need to be 100% assured of working (e.g. direct debit claims) and if so, how will they be tested and what will the fallback plan be in case they don’t work (even after testing!).
11. What input/time will you need from my team during the implementation and at what stages of the project?
    This should incorporate much of the above (i.e. requirements gathering, testing, training) but it’s very useful to get an overall understanding of the sort of work you and your team will be needed for. Is there going to be any need to back-fill any positions for any part of the project?
12. Do we have a contingency for the budget?
    Sadly, projects do go over-budget, so has this been considered? How was it decided, and how will any contingency be approved during the project?
13. What happens if the project over-runs?
    Again, it is quite feasible that the implementation will take longer than initially envisaged. If this does happen, what will the impact be? Can you carry on using your existing database, and for how long? What are the cost impacts? Will there be any impact on your fundraising or planned activities?
14. How will you keep me updated during the project? How will you keep other stakeholders updated?
    A key thing is to ensure that you – and the other key stakeholders in the project – are continually and regularly kept updated. This doesn’t mean you have to meet every week or receive a 10 page technical report, but you need to know how often you can expect updates, how and what will be in such updates. This does go hand-in-hand with point (3) above on project management, but is one of the most crucial parts of that.
15. What will the supplier’s involvement be after we go-live?
    Once you do go-live with the new system, what will the supplier do. Will they just walk away and let you get on with it? Will they be around for a period of time? What other input and help can they provide over the subsequent months (and years).

And having limited myself to 15 questions, there are in fact many more which now spring to mind. But I hope the above provides a solid base for you to start from.

Anyone else got any more questions which they think are useful for fundraising managers to ask? Or has anyone had any experience of when fundraising managers did/did not get so involved and thus when a project did/did not succeed?

Do fundraisers ever really create queries themselves in fundraising databases?

 

Almost all fundraising/CRM software suppliers promote the fact that a key benefit of their system is that fundraisers and “end users” – i.e. non-database/data-savvy/IT staff – can create their own, especially ad-hoc, queries and reports. And I have always wanted to believe this – and often I do! But is it really the case? Surely it must be possible in 2012 – mustn’t it?

Yes, sometimes
In some organisations I have worked with, it does happen. It tends to be in smaller charities where they don’t have much of a dedicated database/IT team anyway, or where an organisation is fortunate that they have got a fundraiser who “really gets databases” and is comfortable with queries and reports, and who can thus do such work. But sadly, this can be rare.

But it does depend…
Of course, much of this does depend on the complexity of the query required – the question the fundraiser wants to ask – the reason for the question and of course the ease-of-use of the software itself. I know a number of packages where to do comparatively simple queries, many fundraisers are indeed able to use the software’s query/report functionality to do this. And if it is a comparatively simple question such as, say, How many individuals live in London, or how many people have given a donation in the last x months, then that is viable.

Of course, the more pedantic of my readers will – quite rightly! – point out that even that requires some thought; e.g. what if a database stores multiple addresses for individuals, do we really want all individuals, what about deceased/gone aways, and do we mean all donations, what about regular givers/legacies… and so on.

The problem is, it is always about the data
And there-in lies the rub. There are of course many such questions which we should ask about so many of these seemingly simple queries/reports. There is a need to think about this, there is a need to know the data and coding structure on our database, and we do need to consider why we are asking the question at this time. If it is to get rough counts then maybe some of the exclusions matter less (or maybe not…). But if we are producing a report for the Director of Fundraising about income from last year then we need to ensure that we know what we are producing is correct.

And I haven’t even started on the need to add a second variable to a question. E.g. find me everyone who has given a donation last year and who lives in London or Leeds. How many fundraisers and end-users really understand Boolean logic and truly know their ANDs from their ORs. And then of course we have nested brackets…

Some software can help
E.g. simple templates, ‘query-by-form’ (rather than a separate query module), cut-down versions of field lists; and parameters are always useful. i.e. many times a fundraiser wants to ask a similar question on different days but just change the city name, the amount in the donation value field etc. So data people can create a standard query for such a request but include a parameter in the query - so when a fundraiser runs said query, they are prompted to enter the city/donation amount etc on-the-fly without having to 'get under the bonnet' of the query to do so.

But it still comes back to the data…

Hence the central data team
All of the above is why so many organisations still have a central person/data team to create these queries and reports. Because the database/data person does understand these points and therefore, as long as they understand the question the fundraiser is asking (another point altogether…and shows again my point of the need for "bridgers" in our sector) then they should be able to create such queries/reports easily enough. I also know a few organisations who have a ‘data’ person in a fundraising team such as Direct Marketing, so that they can specialise in such requirements. 

Or is your organisation different?
Prove me wrong - please! Leave comments below about how you or the fundraisers/end-users in your charity do create new and even semi-complex queries or reports. I'm sure there's plenty of people who would love to know.

Should you ever invest in a short-term CRM solution?

 

Every now and then I am asked by a charity if I think it is all right if they buy a database as a “short term solution”. And for short-term, they usually mean “cheap”. This is normally asked because, for whatever reason, they (say they) can’t invest at this moment in what they feel would be a long-term database but they have to have something now.

My instinct is nearly always to say No, that’s not a good idea. But I have been thinking recently if I am always right to say that:

Why I say No
I normally say no to short-term solutions for a number of reasons:

• It will still take a fair amount of your time and effort, assuming you are doing at least a semblance of a requirements gathering and procurement process, and just because you intend to spend less or only see it as being needed short-term, that doesn’t mean it will necessarily take less time or require less effor. In fact, if you are going to put in this time, why not do it “properly” and get a "proper", hopefully long term solution.
• It is quite likely it will cost you more in the long run. Not only will you have to repeat the above process at a later date (i.e. the needs analysis and procurement), but you will have to invest initially in a database and then invest again at a later date – with all the associated professional services – and of course have to pay a second time for data migration. That means it is extremely likely that you will pay more in the long term than you would do if you spent the time, effort and money now to get your ideal system now.
• Short-term can be an excuse for doing things cheaply and therefore not comprehensively – or to put it bluntly – badly. I am often told it “doesn’t matter” because it is “only short-term” and “we will do it properly” when we are ready. That just means poor decisions all round: a potentially poor system, a non-thought through process and on-going business processes and quite possibly, a system which won’t support your fundraising needs even in the short-term.
• Short-term solutions frequently become long-term solutions… How many times have you implemented any sort of system or process as a “short term solution” only to find you are still using it months or years later.

It’s worth asking, Why can’t you get the investment for a long-term solution?
If you are having to think short-term because you haven’t got the budget for a long term solution, then it might be worth going back to your business case and trying to show why it is so important that you do get the correct and necessary budget for your particular needs. Do you need to show your SMT/trustees the benefits you will get? I would always encourage this first.

What about the “But there is new technology happening soon…” question
One reason I am sometimes told that an organisation only wants to invest short-term is because there is some great new technology which is just about to be launched in a few months... Maybe so. The thing is, new technology is being launched every day! If we wait and wait for “the next big thing” then we will wait forever. You have to do a well structured procurement process, invest in a system which (as much as possible) will be "future-proofed" and invested in by the supplier for the foreseeable future and take the plunge.

So, is there ever a reason to say Yes to a short-term solution?
I guess there are a few scenarios I can think of where I would consider saying Yes to short-term:

• If you invest a small amount in a product in the first place which you intend to invest more in later. In fact, this is quite common and in some instances perfectly good business sense. If you need to start using the database in one department/team and then build-up the system across other teams in your organisation then why not. If you only have a small budget now but you can get started with this and apply for a larger budget for the next year, then yes, this is an option. You still need to do all that in a ‘proper, structured’ way, so that you know you are buying a system which will be scalable in the future, but if so then that could be fine. This is therefore not the same as just "buying short term" because what you doing is planning long term in a good, structured way but simply investing less initially.
• If you are, say, a small fundraising department who needs a system now, but where the long term strategy of your charity is a broader organisation-wide CRM system. In which case, as long as your charity recognises they will be spending money later on integrating/moving you to a new system, then short-term thinking could be appropriate.
• There are of course a few good, low-cost fundraising and membership databases for charities and it is better to consider those in a well thought-through process than just buy one for the sake of it.

But what if I really have no budget for a new database?
I know, this is always a potential problem, especially for smaller organisations. And the temptation is therefore to just "get something in now" because we have to have something, and to worry about it later. But, if this really is due to severe budget restrictions, then this doesn't mean you still can't go about procuring a new database using a good process. Read my recent blog post, What should you do if you really have zero budget for a new CRM or Fundraising database?

How not to buy a database (or anything else for that matter!)

Whilst I was preparing recently for a training course I am planning, I came across a couple of videos which I thought gave a neat, humorous insight into what you shouldn’t do when buying a new database (or any other aspect of IT) - but without always using IT to prove my point!

Enjoy!

1) What if there were no stop signs and a major corporation was charged with inventing one?
This shows so many things we should consider - How do we define something where we think we know what we want but where we have to tell someone else who doesn't know what we want, what we want... How not to change your mind half way through a project, how not to over-complicate it. Are we re-inventing the wheel?! Oh, and many more...
 

2) Cartman and South Park conduct a website review meeting

It doesn't have to be a website, but this is. But it has the same message for a database. Think before you start!

Anyone else got any other videos along these lines which you would recommend?

What should I do if my database project is failing?

 

There may be times when your database or CRM implementation (or other projects) may be failing. Or apperar to be failing. In one way or another. In which case, other than obey the first rule of Douglas Adams, what should you do?

• The first thing you should do is ask, What do you mean by failing? Based on what? And who says it is failing? Is it really failing, really out of control, or is it, for example, just a bit behind schedule at the moment but in reality should pick-up fine next month? Do consider carefully if you have proper targets/metrics which say it is definitely failing – if so, then the rest of this post might help. If not, then consider and discuss more why someone thinks it is failing – it may be that it is not as bad as you or they think and/or that it is not being considered in quite the right way...

• However, if the project is failing then you need to pause and review it. i.e. which means, probably interviewing all the relevant parties involved with the project, plus reviewing the business case/PID, the project structure, targets, constraints and anything else similarly relevant. And use an “outsider” to do this review, whether it is someone from within your organisation but not involved with your project or an external person/consultant or maybe even a trustee.
  
  This will mean you can understand what is really happening, what has happened which has meant you are where you are now and hopefully why it has happened; and it will start to mean you can work out what you need to do and change to resolve the failure and hopefully turn the project around. Thus, it will show you not just the analysable, financial status of the project but the possibly more subjective but no less important “cultural status” or “people problems” too.

• Depending on what comes out of that review, you will have different options. Is the original business case, the interpretation of which might mean that the project is now failing, no longer viable or up-to-date? Do you need to go through the correct steps of reviewing/adjusting that? And if so, with what implications? Do you need to change a significant aspect of the project: Resource(s) in the project team – either changing them or supplementing them? The scope – maybe scaling it back? The timeline or expected benefits – re-targeting the project?
  
  Or is it a good idea to review how to move the project on in terms of ‘breaking it down’ into different parts – smaller chunks with smaller goals, scope and budget? Or…

• Or, do you need to consider if you really should can the project now? Is it really beyond repair? And if so, is that necessarily a bad thing?! Maybe your revised requirements or the original business case have changed so much that this really makes sense. Or do you just need to stop, either completely and recognise and accept the project is no longer viable, or alternatively, maybe start again with a similar but new project, implementing the lessons learned from the failed one so that you can do it right this time.
  
  But do also consider: if you do stop now then what is the cost - the real cost? There are not just the sunken costs you have already spent + the commitments you have to make; but ideally you should also add in what the additional expected income was to be if you did finish the project or the savings you planned to get. And compare that total cost to the (possibly new) cost if you did continue. And also, is there any "cost" of lost reputation internally or externally if you stop the project now? Is that acceptable or worse than stopping?

• And if you are using a third-party supplier, which is especially likely in a database implementation, don't immediately just blame the supplier! It may be just as likely (more likely?!) that there are issues with any of the above points I have listed or with your own staff or processes. That said, it may of course be that the supplier really is at fault, in which case you do need to consider what you should do. Can the supplier change enough for your needs? Or do you need to change supplier? What can you rescue from the project which can be re-used either with the same or a different supplier? How can all the above listed ideas and issues be discussed and adjusted with the supplier?

I have been brought in to manage a project where I have indeed recommended we stop there and then. But I have also been with projects where it appeared to be failing but where, with a few changes, we did turn it around and it was successful. And that can be as great an achievement as anything else.