There is no doubt that the adoption of the generic CRM systems like Salesforce and Dynamics is increasing amongst charities and NFPs. But in comparison to the commercial sector we are still learning about the use of them. And in comparison to traditional fundraising databases (Raiser's Edge, thankQ et al) we still know less about them. Consequently, although there are definite benefits which the CRM systems bring, there may still be issues which we don't yet know about.
Bring on the iceberg...
My iceberg theory…
The fundraising database packages have of course been around for many years. Many organisations have implemented them, many people have implemented them at multiple charities and of course the suppliers have huge experience of them. And they have a more defined scope.
So we know many of the potential risks and issues with such systems (as well as the benefits of course) and when we start an implementation we can attempt to plan for and mitigate such risks. And even though there will inevitably be new risks/issues which occur during an implementation, I could have a good guess at some of the areas that some of those might occur within.
Whereas the opposite is true for the CRM systems - at least in the specific and critical area of fundraising. Because although there are of course existing charities who have implemented Salesforce, Dynamics et al for their fundraising needs, in comparison to the fundraising packages the number is still low. And those that have done may well have used different approaches to each other and very different configurations of such systems.
This is partly because of their newness, but also because of their flexibility, options, configurability and the breadth of functionality in the base platform. You (we) don't learn that overnight. And even as you do learn the system, so we have to apply that to get the best out of them for sophisticated and sometimes significant fundraising requirements.
And it isn't simply a matter of therefore finding an experienced CRM system supplier because they will also only have limited exposure to implementing their system for fundraising at charities and NFPs.
Hence the iceberg…
Because if it is true that 90% of an iceberg is underwater and thus we can't see it as we approach it, then the same could be said of CRM system implementations. In fact, it could be worse. Because at least we know that we can only see 10% of an iceberg above water, whereas actually we have no idea really as to how much of the "CRM iceberg" is submerged below water, waiting for us to hit it as we plough through the sea of implementation. I hope that in practise that we do know more than just 10% of what the potential risks/issues are, but I can't say for certain right now.
Whereas, with fundraising packages, one can almost turn that on its head (an inverse iceberg?) and say that we probably do know 90% of the potential risks/issues which could occur in a typical implementation of such systems.
So what can we do to plan the safe passage of the good ship CRM?
The good news is that although we may not know exactly what is coming to potentially scrape our bows as we sail past, we can have a good stab at knowing the sort of areas in which any issues might impact and thus even if we can't put a final mitigation plan in place for such risks, we can start now to consider how we should plan for them.
What do I mean by that? Well, let's take a complex income processing scenario. Maybe we know that our ideal requirements can be met by CRM system X only through customisation and coding. In which case, we can watch carefully as we start down that route, plan to take it slowly, test as we go along, re-test as we add further functionality, actually go-live with limited functionality and then build on that, and always have a back-out plan which might mean, say, that if we do find it is getting too complex/costly, then at least for the implementation we will decide to simplify the system itself and substitute the ideal functionality with off-line or manual processes instead.
Similarly, if we find that record volumes are causing a problem which we didn't know about for data migration, then we may decide to initially just migrate more recent data and then transfer older data more slowly over a period after we go-live. Or for gift aid claims, we could even have a third-party package ready to do some initial claims if we do hit a nasty bit of ice. And so on.
And overall we can follow good practise for any CRM implementation: get our requirements straight, make sure it is all documented for client and supplier, manage scope-creep, don't let shiny new whizzy stuff take you off down a path which you don't need to go down (at least not on day one), insist on good project management (internally and with the supplier), never forget your operational needs, look for true benefits and so on. Keep it all as simple as possible.
Reeling it back from the simile…
I realise that I am wandering off down the iceberg simile a bit too much, so let's reel it back to finish this post. What I am really trying to say is that we must not forget that some of the fundraising implementations already done on these CRM systems are still pioneers in their own way. We can do as thorough procurement processes as possible, we can learn as much as possible from commercial organisations who are more experienced in their usage and their business partners/suppliers, and we can learn some things from other charities who have already started to use these systems, but because of their sheer size and capabilities we must keep our eyes open and be ready if we hit a problem that we just hadn't thought of. Be ready for this as much as you can, and if that does happen then hopefully it will just be a slight scrape on our midship and we can avoid replicating the Titanic…
No comments:
Post a Comment