Is a CRM/Database supplier more important than the software they sell?

It is a question that has often been asked over recent years: when buying a new database, is the supplier or the software more important? How much credence should one give the possible suppliers? How critical is the software and technology in comparison?


Remember: It’s not just about the supplier/software
When considering the implementation of any database, the first thing to remember is that the supplier/software is in many ways the least important of all aspects. That is not to say that they are not important, of course they are, it is just that there are more important factors. Namely:

• Your underlying organisation strategies/structure: i.e. your fundraising strategy, management structure, IT strategy, communication policies and so on. If these are not in place then it doesn’t matter how good the software is, nor the supplier. Databases can’t improve your fundamental structure.
• Data. Again, if your database lacks data integrity or if your data is not clean, consistent, usable, complete and so on, then the best database in the word cannot help that.
• People and processes. Your users need to be trained, business processes need to be in place.
• Hardware and IT infrastructure. If your server or PCs are under-spec’d or if your IT infrastructure is not up to scratch, then your database will struggle no matter what you have or who supplies it.

So how important is the CRM supplier?
The answer to this depends on 2 or 3 scenarios:

• Firstly, if you are buying a bespoke system, then the supplier is clearly critical. How well they gather and understand your needs, interpret them into your solution, create the software, make it user-friendly and so on, and then support and enhance it – all of that you cannot do without them. If they are not good enough then your software will not be good enough. No matter what database system or programming language they use.

• If you are buying a proprietary package database (e.g. in the fundraising database world, systems from the likes of ASI, Blackbaud, IRIS, ThankQ etc), then the supplier is still very important because they own the software and they are ultimately the only company you can turn to if you need something (even if in some instances, other clients/support networks and third party consultants can help to an extent). So when you buy their software, you are definitely buying into the supplier as well.
  
  However, at least with a package solution, you can see the heart of the system even before you buy it, see what it can do for your fundraising and understand at a fundamental level if it is right for you. So you get a degree of safety.
  
  One could argue that the supplier is more important when you are initially implementing the system because at that point you are most dependent on the supplier, and once you have got it up and running then at least you can manage it more yourself; which is true to a degree. But as you continue to use and grow into the software, then you will probably be wanting more and more from the supplier in other ways in terms of future releases, patches, new functionality, support and so on. So again they will become equally important.

• If you are purchasing more ‘generic’ CRM software such as CiviCRM, Microsoft Dynamics CRM, Pivotal, Salesforce, SugarCRM etc, then it is a slightly different story. This is because the software itself, the underlying CRM database, is developed by one company such as Microsoft, Salesforce etc, but it is implemented and deployed by any such company’s partners or resellers. As such, the partner/reseller you select is very important during the implementation because they will need to get you up and running; but if you did fall out with them thereafter, or if they went to the wall, then you would have other partners/resellers you could turn to instead for support.
  
  The difference here is that you are still of course dependent on the “parent” company providing the software (i.e. Microsoft, Salesforce etc) in that it still of course matters how good the overall software is, because any partner/reseller can only do so much with the system itself. And the parent company will still be the one developing future releases and fundamental functionality.
  
  An interesting angle on this point is that there are now an ever increasing number of partners/resellers who are bringing out “vertical-sector” versions or “templates” of Microsoft CRM, Salesforce etc for the NFP sector, and thus when you buy their solution, you are not just buying the underlying software but also a specific “variation” of it which might be angled to your requirements. This means you get some degree of comfort in seeing how your system could look before you buy it, but you will still be reliant on the specific partner/reseller to work with you to implement and fine tune it.
  
  In addition, you need to be sure to ask each such supplier of these templated versions how the intellectual property (IP) works if you no longer want to work with them in the future. E.g. if you buy a Salesforce-specific templated version for your charity from supplier X, implement it with them but then later decide supplier X is not right for you. Thus, if you, say, stop paying annual support fees to them, but you want to keep the templated software they sold you, then can you do so?

So is the Supplier or the Software more Important?
You will see from my discussion above that this is not such a simple question. Certainly, you should not procure a system based solely on the software if your research shows the supplier to be suspect or if you feel the supplier has so little empathy with you that you will struggle to work with them from day one – it is easy to go down this route, to get blinded by wonderful looking software and just believe that the supplier is bound to be okay. Watch out for this scenario.

But likewise, even if the supplier appears to know your requirements extremely well, then don’t let a supplier’s rainbow vision deflect you from determining if that CRM system is truly good enough or right for your needs.

There is no doubt that the supplier is important. Whether they are more important than the software is questionable, and I am going to sit on the fence here and say they are pretty much equal in importance and it will come down to your specific needs, internal skills, functional requirements, budget and so on – they will influence the answer to this question.

It's not the technology that's difficult, it's Everything Else

I recently visited a comparatively small charity who wanted to extend the use of their fundraising database beyond the fundraising and marketing department. It soon became clear from our meeting that there was no problem with the technology in terms of doing that, they have a good fundraising package and it can certainly manage the other departments’ requirements.

But what was also evident quite quickly was that the main problems with the project would be the non-technology aspects: some objections from other people, training, data migration, standardising codes and terminology, adjusting business processes, finance flows, data protection, the time it would take other departments to enter what they saw as less useful data, record ownership, user licenses, ensuring new users attend workshops, planning future communications, budget… and so on and so on.

All of which just went to re-enforce my understanding and belief about all such CRM implementations in that the technology is the simpler part and the People, Processes and Everything Else is always the challenge. (NB: I’m not saying technology is necessarily simple, just simpler…).

This is of course what I have been banging on about recently to anyone who will listen (and, as anyone who knows me will testify, I can go on a bit…!) and my apologies if I am starting to sound like a broken record. But I hope that if I keep doing so, then even if just a few organisations who read this take on board the message and thus plan their future database and CRM implementations with this in mind, then that will make me feel much happier.

What Makes a Great Database Manager? (Part 2)

In part one of this blog post, I started to lay out what skills and attributes a great database manager has. Here's the second and final part of this post.

Subject (Business) knowledge

The best Database Managers I have worked with are those who (if necessary, learn to) understand the charity’s business requirements (almost?) as well as the database system they manage. End of story. They are the people who know that the best benefits you will get from the database will be those which match and enhance the organisation’s requirements. For example:

• Fundraising/Membership/Services knowledge (etc): I realise this can be very broad but if a Database Manager can talk at least to a certain level about major giving, direct marketing, alumni management, membership and so on, then that is going to help so much. They will then learn and understand what the Fundraising Managers (et al) want and can interpret that and apply it to the database. It’s quite a skill but it’s what makes a great Database Manager.
  
  Managers and end-users have often told me “I don’t know what I want because I don’t know what a database can do…”, so if your Database Manager does know what a database can do and can they can learn the charity’s business then you are on to a winner.
  
  Two specific areas within this topic are: For UK charities, Gift Aid knowledge - if your Database Manager will be working on a database which manages gift aid, then if they have knowledge of gift aid itself then that will help enormously. And Web 2.0 in terms of being up-to-date and savvy about how all the latest social networking and web 2.0 possibilities could be applied to fundraising et al.

• Data Protection (DP) knowledge and Awareness of legal issues. It’s incorrect for a Database Manager to be ultimately responsible for DP and legal issues, but it’s pretty important that they can at least discuss the issues with some knowledge of the subject.
• Finance knowledge. If your database records income then it will help enormously if your Database Manager understands or can learn the nuances of your financial requirements, coding and systems. This means on the one hand appreciating that fundraising and marketing might require one set of codes but on the other, realising that reconciling income with the charity’s finance system might need a different approach.
• Knowledge of Statistical Analysis/BI-savvy (Business Intelligence): For some organisations, especially those with larger data sets, for the Database Manager to have some knowledge of statistical analysis is quite a bonus. Hopefully, they will be able to work with your other staff in determining what statistics are required, how to get them and what they mean etc, but the more input a Database Manager can give to any such discussions because of their knowledge of statistical analysis is a bonus.
• Project Management skills. Many aspects of database development are project based, and whilst some will be small or simple, others might be more involved or run over some months. In which case, having some Project Management skills is a great thing for a Database Manager to have. I wouldn’t expect them to be PRINCE2 trained but if they can show they have the sort of skills which fundamental project management needs then that’s a great thing to have.
  
  What are those skills? How about: communicating to their team and others what is expected of them; maintaining a project plan; co-ordination and centralisation; monitoring resources; understanding task dependencies; risk assessment and issues management; supplier liaison. And potentially much more of course. Okay, this is a heck of a lot to ask for a Database Manager to do, but if you find someone who can then snap them up!

Soft skills

Obviously, soft skills are not just specific to a database manager but here are some which I think great Database Managers have:

• Building relationships, especially with other departments. The database is almost by definition going to be used by multiple teams and possibly different departments. So if your Database Manager can build those relationships well then that will help.
• Diplomacy, empathy. Absolutely!
• Communication: verbal and written. If there was a sub-context running throughout this post [and my eBook], then communication would be it. I have highlighted the need for good verbal communication constantly, but it is also important that a Database Manager has good written communication skills. It is likely they will be writing emails, reports and specifications which others will have to validate, so they need to be able to do so clearly, non-ambiguously, without over-using or un-necessarily using technical jargon and in a structured and readable way. This may sound an extremely obvious statement but you wouldn’t believe how many examples of bad reports and specifications I have seen (or maybe you would!).
• Pro-active. I think this is a really key skill that great Database Managers have. And on two levels: one, at a pure database level, i.e. ensuring data accuracy, reviewing security rights etc; and secondly, at a “business” level in terms of potentially understanding fundraising (or other) opportunities. This is a real bonus if your Database Manager can do the latter – sure, your fundraisers/staff should be able to ask for information and work with the Database Manager, but very often, database people are far closer to the data than other staff, so if they see something which might be of interest and can communicate that effectively to other users then that’s great.
• Time Management. As for all jobs.
• Managerial and delegatory abilities (where they are managing a team)
• Planning: A good Database Manager plans (and loves to plan!). They don’t jump in with two feet without considering all aspects, without testing, without asking just why someone want to do something!
• Obsessive about accuracy! Great Database Managers love accuracy! They are almost anal about it. And detail. Everything should be in its place, done in the right way.
  
  That said, great Database Managers also understand when such obsession is getting in the way of the business and when to let go of a particular instance of when something isn’t done quite to their preferred level of accuracy (if only for a while, until they can come back to it!).

The X Factor

If you can train someone in technical and business knowledge and hopefully soft skills, then why are some individuals better than others? Do they have the X-factor which means they just get it a little bit better…

To a degree, this sub-section is re-iterating some of the points I have already made in this post, but it also adds a few and brings them all together to show what such a person might have.

• Database and Business Understanding. As already discussed, when someone has great database skills and a great understanding of business requirements, and they can tie the two together, then they have all the makings of a great Database Manager.
• Analysis and questioning skills. It is quite an art to be able to ask users about their needs, gather all such information, collate it well, translate it into language which everyone can understand and then implement it… but if at the heart of this, you haven’t done the analysis then the risk of not giving users what they really want is increased. Great Database Managers can do this.
• As I mentioned before, often users will say “I don’t know what I want because I don’t know what a database can do…”. So if your Database Manager does know what a database can do and can they can question a user well enough to learn what they really want, and match the two together, you are on to a winner.
• Problem solving (and tenaciousness). Refusing to say no when a software supplier tells them that something isn’t possible in their database… Okay, they say, so how can we approach it differently, find an alternative, ask the question differently - how can we do it anyway?
• The Ability to Perceive Patterns. This is just one of those things which some people have. As discussed before, Database Managers are closer to the data than most other people, and unless your organisation has specialist data analysts, then it might be your Database Manager who sees new issues and opportunities. Seeing patterns in their data, whether good or bad, is something which sets individuals apart.
• Pro-active. Everything I said before. 
• They strive for automation. Database Managers much prefer automated routines to the risks which manual data entry, imports etc bring.
• They have gravitas across the Organisation. This is quite something and pretty hard for a Database Manager to achieve. To be someone which senior managers and influential users respect and go to, to create a culture whereby they are considered and consulted when a key decision which might just affect the database is discussed by another department. If you have that, then you’re a great Database Manager.
• Slightly geeky…?! So, having said everything I have said in this section, I still like it when a Database Manager is just slightly geeky!! I don’t mean that they want to run everything on Linux or that they name their servers after planets on Star Trek, but I want my Database Managers to like databases! I want them to enjoy working with databases, to somehow find them aesthetically pleasing. That’s a certain style of geek which I love!

(This post is an extract from my free, downloadable eBook, "How to Interview and Employ a Great Database Manager").