Why Do we still need so much training for Fundraising and CRM systems?

 

Over the years, there have been many promises about how we would need less and less training on our new fundraising and CRM systems, but in my experience, most new database implementations still require a fair amount of training. So why is that?

(First things first: there are whole books and thesis written about the best way to provide training on IT systems, so I have considered this blog post for just a few top level points - if you want to dig down further into the area then there is plenty more reading out there.)

We do have to remember that a fundraising or CRM database is not like a word processor or smartphone app. Fundraising/CRM systems are sophisticated and large applications, and, critically, they are also at the heart of our business operations and all our processes. So whatever we are implementing, they are going to take more time to learn than other software systems.

Secondly, because these systems are so sophisticated, flexible and broad-ranging, the administrators and database managers are going to require in-depth training and that isn't going to take a short time. There will almost certainly be multiple days training for such people.

And then we have the 'end-users'. Clearly this is where the bulk of the training needs to happen. And this is the area where we might be able to fine-tune and streamline some training courses for these people. Many vendors and organisations have moved on from the 'day 1, day 2, how to use our system' type training, and are realising that training the users around their particular business processes and specific instance of the system is a better way to do it. However, except for the very simplest of needs, even that is going to require a bit of time. And, as I said before, because in effect we are not just training on the software but reviewing the business processes too, and the users are having to understand how they have been impacted with the new system, then all that will add-up.

Which is why there is still so much training needed for most implementations of fundraising and CRM systems!

And a final word on some vendors: if you get a software supplier who tells you that you/your users don't need any training "because the system is so simple/intuitive…", then take that with a pinch of salt. If that's the case then not only must the software be so simple to use that anyone can start to use it without any problems or asking any questions, but they clearly also know all the new processes without any training either. Sorry - I can't see that happening.

Just what the heck IS a 360 degree view?!

 

"We want a 360 degree view of our supporters," or "We can offer you a 360 degree view of your supporters" are much-loved expressions these days. By charities and by CRM vendors. And when it's said, everyone nods their head earnestly and agrees, Yes, that's exactly what we need. And why wouldn't you? It sounds great! But does everyone really understand what they mean by a 360 degree view? It may sound simple/obvious (?) but is it really?

Let's have a look at a few definitions I found with a quick online search:

• Experian: "A 360 degree customer view gives a full picture of your customer and is essential for your organisation." Essential? Ooer.
• Aberdeen Group: "Buyers [donors] benefit from better service and efficiency, and sellers [fundraisers] derive improved loyalty and, inevitably, more repeat business from established customers." Okay, that sounds better.
• 360degreeview.com: "The 360° Customer View creates an integrated view of the customer – right across your enterprise. It gives you a business framework for integrating, enhancing, managing, and analyzing customer information, and allows for customized, phased implementations that deliver measurable business benefit." Wow, that sounds amazing!
• Purple Vision: "Everything you know about each supporter in one place." Ah, good - nice and simple.

So are they all saying the same thing? Well, yes and no. To answer that we probably have to first ask two fundamental questions: Why do we want a 360 degree view? And then, What data are we actually storing in order to provide one?

So, why would someone want a 360 degree view?
One of the most common data - and thus fundraising - issues for a charity is that there are so many data silos in an organisation; i.e. multiple databases and spreadsheets. And therefore, we can't see every contact point (often called "touch points" if you're being data-cool) which a donor or supporter has had with us.

And if that is the case, then: we might be contacting them without knowing specific things about them; we might contact them inappropriately; different people might contact them without knowing a key point about the supporter; multiple people might contact them at the same time for different reasons and risk losing, say, a key donation; we might not be maximising the most we could get from a supporter; we might not be keeping up with data protection/FOI requirements; we might not be able to analyse a supporter/groups of supporters as comprehensively as we could do - and as importantly as all that, we might not be treating the supporter as they would like to be treated.

These are all good reasons for potentially wanting a 360 degree view.

So what about the data itself?
But even if we want a 360 view and we know why we want it, then what should that view show? Does it really have to show "everything" about a supporter? And even if it should do, can it?! Can we ever see/collect all contact points?

I guess, ideally, yes it should show everything - that is the only way to really see a "complete" picture of a supporter. But how do we really know we are collecting everything? Is everyone in the charity entering every interaction with every supporter? Unlikely. Or even if they are, then it could well be on a local version of Outlook, a spreadsheet somewhere, a third-party online database.

I should also clarify "everything". A 360 degree view does not necessarily mean creating one behemothic, single database which is your only database where you store all your data. Very often, a 360 degree view (almost by definition of "view") will just contain key data sourced from multiple databases within your organisation - just enough to ensure it can do... whatever it is you are trying to do with the 360 system.

So do you really want one?
Could be. Their potential benefits can be great. And don't let my last few paragraphs stop you from trying to create your 360 degree view if you do decide it is right for you! Even if we can't definitely say we are collecting everything, then that isn't a reason not to try to set-up a 360 degree view if you see the benefits of having one for your organisation and your needs. Just be aware it might not be everything. Start-off with what you know and build it up as you find more sources, more people who might use it and as you identify more benefits from doing so.

Finally, assuming you do have multiple systems at your organisation - highly likely no matter how centralised you try to make a centralised CRM/fundraising database - then there is always the technical challenge of actually achieving a 360 degree view. That is not always as easy as one might hope.

Should I change my processes to match the database or make the database change to match mine?

 

This is a very common question I am asked: When I get a new database, should I change my processes to match the database and how it works, or should I make the database change to meet our processes? My views have actually changed on this over the last ten years and my own beliefs are now as follows:

First, It Depends...
First, there are a few "it depends" factors in this answer; the most important being:

• Why your current processes are as they are. In my experience, there are three common answers when I ask "why do you do process X that way?": (i) "I've no idea, we've always done it that way…"; (ii) "Because the current database makes us do it that way"; and (iii) "We've thought it through carefully and this is the best approach for us". Sadly, the latter answer is rare and the first two, and a combination/variation of those is more likely.
• Legal issues; e.g. gift aid, monitoring restricted funds etc. In these instances, the processes are going to have to reflect what is legally required anyway (although even here there could well be different ways to approach some of them).
• The type of database you are implementing; i.e. fundamentally whether it is a vertical-sector (traditional) fundraising database package, or if it is one of the newer breed of generic CRM systems. Although this difference is blurring a bit as I will explain below.

Why Wouldn't You Review Your Processes?
Secondly, when you implement a new database, whatever you buy, reviewing your processes is one of the most useful things you can do. As I said above, unless you already know you are in the "This is definitely the best process for us" category (which is rare), then this is a great opportunity to review why you do something, how, what's good about it, what's bad, what takes time, what could be automated, what you don't need to do and so on. And then you can take all that knowledge to the database implementation so that you can review the best way forward with your new system.

What if you are implementing a Traditional (vertical-sector) Fundraising Database package? e.g. Raiser's Edge, thankQ, Redbourn etc.
Many of these systems have been designed and adapted with many years of experience of what the NFP sector requires. And most which are still being sold today (if not all) are still selling and being used because they do the fundamentals perfectly well. And therefore, if you are buying into them as a software package, as a system, then it would seem to make sense to me to adapt your processes to how the packages have been designed. If you aren't going to do that, then why have you bought that package in the first place? There may be tweaks to do, but I wouldn't recommend changing the systems themselves except for the bare minimum and definitely within any parameters which the supplier suggests.

What about "generic CRM systems" such as Microsoft Dynamics and Salesforce, which you are implementing from a "vanilla" version (i.e. 'out of the box')?
These systems will give you an incredible amount of flexibility - which unfortunately is a double-edged sword. On the one hand, that means you can probably adapt the system to whatever process you prefer (within reason), so if your process review identifies some potentially great benefits by doing a process a whole new way, then this might be a great opportunity. Although that will also have the potential of higher cost, longer time, more arguments (sorry!) and a more complicated system than you might have needed. You need to be very good at keeping a lid on the amount of change you plan. And also: if you can do (nearly) anything then where do you start?! How will you know if your new process really is the best approach? How far should you go when changing the database system? And if you end up with vast swathes of changes then do not underestimate the Change Management you will need to introduce to your organisation. 

What about generic CRM system with a "fundraising/membership template"? e.g. Supporter360, Silverbear.
There are now quite a few "templates" which suppliers have created to sit on top of Dynamics and Salesforce in particular. In this instance, you are probably somewhere between still being able to change your processes if you really want to, but because the templates will have their own starting point, it would still be sensible to be using them as a starting point for reviewing your processes. Otherwise, as with packages, why buy them?

So What Is My Final Answer...?
My personal belief is to keep change as simple as possible, to use the software as it is supposed to be used as much as possible and if necessary, to start simple with the changes and fine tune them (or change them more dramatically) over time. i.e. Unless there are good reasons not to, adapt your processes to the software.

As I've discussed before, it is only after you really get to know your new software that you will truly understand what it can do, how and the benefits it can bring, so I wouldn't advocate spending huge amounts of time and money on it until you know what you really want from it.

Project Premortems: A Great Tool to Help Mitigate Project Failure

 

It is well known that CRM projects can fail. Just choose a number, any number: 35%? 60%? Whatever the figure really is, it's significant. So I was very interested when another sector consultant, Richard Collings, sent me a link to a fascinating article written some years ago now about a concept called the Project Premortem. And I liked it so much, I thought I should share it.

It works like this: We all know about compiling Lessons Learned after a project has finished (a post-mortem if you like). Instead, a Premortem is held at the start of an implementation (or even during it I guess). It starts by gathering project team members in a room and telling them that "the project has failed catastrophically". Then you ask them to imagine why that has happened. Everyone writes down why they believe the project has failed so badly and then you discuss it. And anything goes. People shouldn't hold back from airing their concerns and should not worry about offending others or upsetting senior managers etc. (Or: if you think that some staff might not be so open/honest with, say, a senior director present in the room, then I guess you could hold multiple such sessions).

The theory is that by doing this, it gives people a chance to air their concerns in a specific, safe environment, when they would not do so in normal working mode. And it makes us think differently too - more imaginatively (and maybe even as a bit of fun!) The scenarios given in the original article are excellent examples to show the sort of things which people might say. For example, the project sponsor "left during the project" and interest in the project waned thereafter; or one I might add: the supplier "under-estimated the work involved with a mission critical function" and therefore the whole project stalled by several months.

I really like this. I am currently working on a large CRM project and we have decided that we will definitely use this technique when we do kick-off the implementation.

As the original article says: "Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t… It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project." And as it goes on to say, "Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them." What a great idea - let's bring premortems to the fore!

---

Since writing this blog post, I have also heard the wonderful Freakonomics podcast air a recent episode in which the author of the original article, Gary Klein, discusses this whole concept. Well worth a listen.

The hardest part of a database implementation is the post-live period

 

This has become a little bit of a hackneyed expression these days. To say that the you won't experience the hardest part of implementing your new CRM system or fundraising database until it goes live. "That's when the real work starts," you'll be told. But for good reason - because very often it's true.

Why is this?

• Only at this point do you truly find out how the software is working for you. You can test forever and get as many users involved as possible during the implementation but it's not quite the same as once your staff are using the new system in anger.
• Your implementation project was hopefully funded correctly, but sometimes there is less budget or even no budget for future work after go-live. Yet, many implementations/systems will still require more work on them at that time. Some of that work may have been planned for a future roadmap but some may only have been decided during the implementation, for example, if you had to cut-back on (or change) the scope. 
• Resources (people) in particular will be 'back to normal' but potentially with different demands and requirements.
• There will be an impact on your users such as pressure on your database team, potential drop in productivity for some areas of use on the new system, processes still being optimised and so on. Read my recent blog post on The Immediate Effect of CRM System Change On Staff for a more detailed discussion on all that.
• There are bound to be things you didn't know about, you had thought you had tested but slipped through the net, that users didn't tell you correctly etc, and it's only when you go live that these issues will surface. Or things may have justifiably changed anyway, which will still cause issues.
• The enthusiasm and adrenaline which the implementation project had may wane. 
• The benefits which were envisaged/promised before the project commenced might not turn out to happen. Some may be understandable or yet happen soon, but others could have been over-sold or had too much expectation.

So what can you do?

• If possible, keep some of the implementation project team for 'as long as possible' after go-live. Three months is a decent rule of thumb for the average sized fundraising database; hopefully by that time most key issues will have raised their head.
• Prepare for some of the above as much as possible! At least those points you can prepare for, such as resources, expectations, impact. 
• Understand resource implications in particular.
• Have a plan for how to handle the new things you didn't know about - not the things themselves but a process for how to manage them when they crop up.
• Explain all this to your SMT early as possible in a project - even during procurement. Get their understanding, acceptance, awareness and support - whether financially or otherwise.
• And my personal belief is that doing a "Phase 2,3,4 etc" implementation is not the best approach. Instead, use a 'rolling development' plan with a roadmap. Read my separate blog on this: Why it is a Bad Idea to have “Phase 2” of a CRM Implementation (andPhase 3, 4, 5…)