End Thought for 2010: Keeping it Vanilla

There has been a common thread amongst CRM implementations I have been involved with this year, and on various other blogs I have read and conferences I have attended: keeping your CRM implementation Vanilla.

This is an IT/CRM term which may sound vaguely amusing if you have never heard it before, but it is one of the more important things you can consider when procuring and implementing a fundraising/membership database or charity CRM system. What it means is that, as much as possible, you implement the database in the first instance without any - or with minimal - “Customisation”; although “Configuration” is fine. (NB: All packages will allow “Configuration” to some degree and if they don’t then don’t buy them).

Why is Vanilla so Important?

Why do this? Quite simple: it will improve the simplicity of implementation, lower risk, create a faster implementation, a lower cost implementation, there will be less need for specific/expert resources, it will be a simpler and quicker data mapping from your existing database, enable simpler testing, you’ll avoid scope creep and more. All these things will mean that your initial implementation will be smoother and have a far higher chance of success. If you are buying a powerful or flexible database then it will be immensely tempting to jump straight in and implement lots of exciting Customisations from the word go, but if you do then you may not receive those benefits listed above.

Defining Configuration & Customisation

So having said that, I should define the two key terms: Configuration and Customisation. These are my definitions below and even if you or some suppliers don’t agree with all my points, the heart of the message is the same. Different suppliers will define these differently and claim different things, so at the end of the day, you need to discuss these issues with any prospective supplier and understand, in some detail if necessary, just what you can and can’t do in each of the following areas.

Configuration. It is Configuration if...

• You use an application’s built-in tools to make changes to the system which every other organisation using this package could do and recognise if they were to start working at your charity.
• If an upgrade/new version of the package was released tomorrow, then you could install it without worrying that any of the Configuration which you had done would mean that the upgrade wouldn’t work, and equally, knowing that the upgrade would not affect any of the Configuration you had done. In practise, some upgrades might still require some such work so if that is the case for your system then do spend time to understand just what that it is. (And of course, whatever the case you always need to test upgrades anyway before going live with them.)
• The changes could probably (if not always) be expected to be done by a “non-techie”. This doesn’t mean an un-trained person and it doesn’t mean a non-database savvy person, but to put it in perspective, I wouldn’t normally expect Configuration to require any programming/coding, i.e. writing code in VBA, XML, C+ etc. This might not always be true but as soon as you do get to this level of “Configuration” then in my experience it is likely that you are starting to get to “Customisation”. Either way, ensure again that you know the impact.

Customisation. It is Customisation if...

• The implementation involves bespoke changes, new modules, hard coded programming etc which the supplier or a third-party does for your organisation for your specific needs. 
• If the work does mean that upgrades/new versions are affected (either because it stops them happening or because your Customisation would need additional work to be done on it).

So should you ever consider Customisations during an implementation?
It is of course very easy for me to write this and say that you shouldn’t do Customisations but do I think you should ever consider Customisation during an initial implementation? Of course you can! Consider but always ask yourself if they are definitely needed. But if you have a critical business function which is required immediately on go-live and there is no other way to achieve it, or you will get so much benefit from a Customised approach that it just makes sense, then go ahead, see how you can implement it. In particular, if a Customisation only has an impact on an “isolated” part of the system (or as isolated as one can expect in a CRM system), as opposed to a core area then that should lower the risk. One thing you could also do to mitigate some risk would be to discuss with the supplier whether could they take your proposed Customisation and build it in to their standard product in a future release.

And do remember that you can of course implement Customisations later, after your initial go-live. Why is this better? Because you can implement them in a more structured way, at a better pace, spreading costs, with less risk, increase user adoption and do it as you learn the package and all its capabilities. In fact, as you gain knowledge of the package, you might even find that some complex Customisations which you were planning originally can be greatly simplified or might not even be needed at all. Don’t shy away from those which are needed or which do bring you benefits, just take them on at a pace and structure which you can implement more easily.

Are there downsides to this approach?

All that said, let me also say that if you do follow my suggestions here then there may be downsides, or at least issues to overcome, for example:

• End-users will (hopefully) be excited by the prospect of a new system, and if they have been sold-on and told about all the wonderful new, whizzy things it can do - which require Customisation… - and then find they are not included when they first get to use it, then they might be disappointed and user acceptance could stall; especially if that doesn’t improve their processes or, say, some screens/forms are not as they would ideally want. So you need to address this early on during an implementation and explain to the users exactly what they are going to get and when – and why you are doing this - and ideally give them a roadmap as soon as possible for future developments of the implementation to show when they can expect the elements which do require Customisation. 
• Those great Customisations you planned for later never quite seem to happen… This is one of the higher risks of this strategy if you do not build-in a structured approach from the word go, especially for charities, where money is often tight. If you are not careful then what you start with will be seen as perfectly okay and if it's working then why do we need to do more work on the system anyway…? To avoid this, ensure you explain and discuss your proposed approach with your Senior Management Team/budget approvers early on in the procurement or implementation phase and get their full support and a committed budget for the post-live Customisations.
• And just to re-iterate what I said above: if you do require a specific function and Customisation is the only option or the best option, then don't shy away from it.

Remember, Vanilla is not boring, it’s a great flavour because of its simplicity!