Wednesday, January 25, 2012

Different ways you can implement generic CRM systems for fundraising

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

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

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

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

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

Benefits
  • You are not reliant on a supplier
  • It is a flexible approach: you can do it as you want to, do the changes as you go along; good for Agile development?
  • You might have a dedicated developer for your needs
  • The cost could be good…
  • You can integrate any third party app you want
  • You will have no issues of Intellectual Property (IP) in terms of development or with future changes (i.e. compared to the IP points detailed below)
Downsides
  • You may be re-inventing the wheel
  • No input from suppliers or, through their experience of developing other systems, other charities/NFPs; and maybe less experience of using Salesforce/MS CRM etc itself? And not just in the initial implementation, but on-going over the subsequent months/years too.
  • You need a dedicated developer(s) with these skills
  • What happens if your developer leaves half way through the development? 
  • How will you be supported after you go-live? How will you maintain the system if/when the developer leaves?
  • Cost could be high compared to buying a template or even getting a supplier to help?
  • It may well take longer to implement
  • You need to know of or find out about appropriate third party apps

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

Benefits
  • Such companies can be flexible: they can get the system to (hopefully) do what you want
  • All their experience (a) of developing fundraising systems on this platform, and (b) of the platform itself and appropriate third party apps
  • Not reliant on an in-house individual and any vagaries of such employment
  • Cost might be better than doing it in-house? Will depend on scope.
  • On-going support
  • Should/could be quicker than in-house development?
Downsides
  • Still potentially re-inventing the wheel to a degree
  • Any IP issues?
  • Reliant on the supplier’s interpretation of your needs, their proficiency, business analysis skills – you will need to manage these risks
  • Reliant on the supplier’s knowledge of fundraising
  • They may have preferences for third party apps which aren’t best for you?
  • Unless you have a supplier who you keep as a support company, you will need to keep on top of future developments and enhancements on the system.

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

Benefits
  • Should be far less need to re-invent the wheel
  • Their experience of fundraising requirements, the platform and input from other charities who have already implemented it
  • With other charities also using it, you should get more proactive changes in months/years to come (i.e. a la dedicated Fundraising packages)
  • Could well be cheaper for basic requirements (but see below too)
  • Should be lower risk because you are seeing more of what you are getting up-front
  • The approach should prove to you whether the company are (or are not) so fundraising-savvy
Downsides
  • You will be more tied to their version than if you developed the system from scratch - but that is of course what you are buying! (It would obviously be useful to compare different templated versions if you can, if you have time/resources and if that is appropriate for you).
  • You will probably still need bespoke work on top of the template, so is there a point when it becomes not worth buying the template?
  • You need to consider IP issues far more carefully. i.e. if you are buying a company’s template, then can you make your own bespoke changes to that? (Unlikely). And if in later years you decide not to use their services, can you still continue to use their template?
  • On-going costs can add-up if you have to pay annual costs for the template version plus any third-party apps you use.
  • Still reliant on the supplier’s interpretation of your needs, their skills, business analysis skills – although hopefully less so than building from vanilla. And you can see what they have done so far so you will get a good feel as to whether you think they are good enough or appropriate for your requirements.
  • They may have preferences for third party apps which aren’t best for you? And if these are more tightly built into their version, then it may (?) be harder to get others?

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

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

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

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



 

No comments: