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").

What makes a great database manager? (Part 1)

I have been fortunate to have worked with some great Database Managers at some of the charities I have consulted for. At least, I think they were great. But I have often wondered what it is which makes a great database manager. Why is it that some people have really stood out when I worked with them? Can we actually define what makes a database manager "great"?

Here’s my thoughts on that - and it's a 2 part post because (as usual!) I have quite a lot to say...

My Definition of a Database Manager

First off, for the purpose of this post, I thought I should try to define the sort of role/person I am writing about. This is because the job role of “Database Manager” can mean a number of different things depending on the type of database, size of organisation and database team, the specific tasks they are expected to do and so on. So here's what/who I am thinking of:

• I am presuming that the role is not purely for a “techie” who would only look after the “back end” of the database and who would rarely come into contact with end-users, application users, business users et al. As such, for the sort of Database Manager I am considering, it shouldn’t matter too much if your database uses SQL Server, Oracle, MySQL, Access or whatever.
• They are someone who is more likely to be working with the “application” than the back-end; e.g. they would know (or could learn) The Raiser's Edge, an IRIS system, Salesforce, DonorPerfect, ThankQ etc. 
• They are therefore highly likely to be someone who would have regular interaction with end-users and business users, so they need more than just technical skills. They need some technical skills, but how much depends on each specific organisation.
• It is likely that they would not be part of the IT department in a charity – although that isn’t critical.

I do recognise that when it comes to a Database Manager, the size of an organisation can have a significant impact on their role and responsibilities. For smaller charities, they could well be looking after the fundraising database package, trying to write a temporary Access system and do the daily backups, whereas in a larger organisation there might even be a team of people who “manage” the database, which could mean that each individual could have different roles (e.g. data loading, support desk) and the head of that team might be far more of a “classic manager” than simply a database person.

And there are more ways of defining such posts too; I’m absolutely sure that for every person who agrees with one of my statements above, there will be someone else who disagrees! And that’s fine! All the above is not to try to enforce a structure on you or your charity, but to help you understand the sort of person/role I am considering when writing this post.


Experience

Okay, let’s start with the most obvious of statements but one which we should never ignore: experience is great! You can read lots of books, go on a training course and even get a degree but experience and learning and using software every day and working with end-users of all sorts and presenting to Trustees and doing things right and making huge mistakes… is all the sort of stuff which really means someone can become a great Database Manager.

Of course, having experience alone does not make someone a great Database Manager. If someone has 10 years of experience in one product but can’t hold a conversation with a business manager then they may not be right for you.

But let’s not forget how important experience is throughout every topic I list below.


Technical Skills

Clearly, a Database Manager would have some technical skills. (I detail below what I mean by technical). To what degree does depend on the system, the users, the size of the database team, even the type of fundraising etc. I know quite a few arts organisations who have a part-time database manager for their development database, and whilst I don’t think that is the best idea, they do get by, and in many such instances I am sure that the database manager does not describe themselves as technical!

• Application skills. If your organisation uses The Raiser's Edge, Salesforce, DonorPerfect etc, then your Database Manager should have a solid understanding of that system. And if they are the sole individual looking after that system then they will need to know or be able to learn in-depth knowledge. My only caveat is where the Database Manager is actually a manager of other people in their team, in which case, if such people are the “do-ers” then as long as the Database Manager knows what is possible, understands the implications, can discuss it at a good level and so on, then even if they can’t do it themselves that may not be so critical.
• Other technical skills. All the following could come in useful:
• Excel and Access. For the sole Database Manager who might have to import data, clean data, extract data for mailing houses, review data outside their database, present data differently for managers etc etc, Excel and Access are great tools.
• SQL. Whilst many packages do not require a Database Manager to have SQL skills, there are increasingly more systems where if they do have SQL skills, it can add an extra dimension to their data extraction/reporting capabilities. And for some systems which don’t have built-in query tools (or weak query tools), it is almost essential.
• PC/Windows skills, Network-savvy. It’s always useful to for a Database Manager to have at least a fundamental knowledge of Windows and at least the benefits of what a network brings (!) as they will no doubt get involved at some time with installation issues, security rights etc. I wouldn’t expect them to be able to resolve such problems but to understand the implications is a good thing.
• “Web skills”. As above, most Database Managers wouldn’t be expected to have to program in HTML or JavaScript, but again a solid appreciation of web knowledge, database/web connectivity issues and so on can help.
• Report Writer skills; e.g. Crystal Reports, SQL Server Reporting Services, Access report writer. Important if your database system uses such packages to create reports and you are expecting the Database Manager to be able to design or upkeep reports.

• You don’t need a degree in IT. It will give you a good base of understanding but I would never worry about employing anyone because they didn’t have one!

Data Skills

I have separated Data Skills from Technical Skills, but some data skills are no doubt a sub-set of Technical skills.

• Data Quality. It’s vital that a Database Manager understands and appreciates Data Quality needs and issues and why it is so important: data accuracy and data integrity (and everything that infers), data cleanliness and consistency, up-to-date data and trust in the data; how to encourage and improve data quality, what can be achieved and what can’t be enforced, business issues and requirements, legal implications, financial implications and so on and so on.
• The specific ability to consider and understand impact and dependency. It is quite a skill when someone can consider and understand what the impact would be if a user asks for a change or addition to a database. How would it impact existing data? Could it affect reports? Would other users find it useful as well? Could it be ambiguous? Are there security issues? And so on. It’s a key thing for a great Database Manager.
• Data Models/Data Structure. I think it is important that a Database Manager understands the basics of data models and definitely “gets” data structures. For example, they must know why different data types are important and relevant (i.e. free text, look-up tables, currency fields etc) and the difference, relevance and importance of “one to one” and “one to many” data structures, even if they don’t think of them in those terms. i.e. a “one to one” data item is something like a First Name or Date of Birth, where each person only has one of each, whereas a “one to many” are entities such as donations, communication records, hobbies and interests, where each supporter could have multiple such records.
• Entity Relationship (ER) Diagrams. Going a step further, should a Database Manager understand ER diagrams? Possibly if they are using a database where they will be regularly running SQL queries or if they are going to be involved in designing a system.
• Data transfer skills. If your Database Manager is going to be involved with transferring data into, and to a slightly lesser extent, out of the database, then having good knowledge of Data Transfer issues can be a real benefit. Not just on a pure technical level but understanding how data files “link together” when importing them, the issues and implications of updating one-to-one and one-to-many fields, auditing, why URNs (Unique Reference Numbers) are so important, data integrity (again!), testing… and more. Larger organisations may have a dedicated resource to do this, but if you just have one person managing your database then they need to understand Data transfer – there’s no easier way to ruin your data than import thousands of records incorrectly!

In Part 2 of this post, I will look at a how a great database manager needs Subject/Business Knowledge, Soft Skills and the X Factor...

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

What Should be in a Business Case for CRM software?

Many charities do not create a proper business case before procuring a new database. And by a business case, I don’t simply mean a few bullet points which show why a new database is needed – I mean a comprehensive document, structured in an appropriate way which addresses all aspects of a business decision. If you do this, then you will be far more likely to succeed: you will understand your key requirements, success criteria, user involvement, constraints, risks and more; and when the project is completed, you will be able to measure its success against the criteria laid out in your business case.

So, what should a full business case encompass? Consider including the following:

• Management Summary 
• Project Background
• Document Purpose
• Document Audience
• Business Problem / Key Issues
• Project Objectives
• Alignment with Strategic Objectives
• Benefits
• Scope (inclusions and exclusions)
• Project Approach
• Project Deliverables
• Stakeholders
• Budget
• Timings
• Risk Assessment
• Resources
• Assumptions
• Constraints

Whether all these areas are needed and how much detail you need to include will depend on your specific project: it’s size, complexity, reach, risks, potential impact and so on. But do one – it is one of the best things you can do to focus senior managers’ minds on the real and fundamental issues involved. Especially when you ultimately ask for a budget.

(The above text is taken from my ebook, "101 Tips  on How to Buy Fundraising Software and Charity CRM Systems". To read another 100 tips, you can purchase the book here).

Getting Discounts on CRM Software: It's Usually Good News But Be Careful...

If you watch The Apprentice on the BBC then you will have seen the would-be apprentices desparately bargain for discounts in last week's episode. (1p off a top hat was a record low discount for any series, I think!) And quite understandably, some of the suppliers in the program refused to give any discount at all: this is the price of our product, they said, so pay it. Fortunately, in in the "B2B" world of commerce, discounts are more readily expected and sometimes given. Although it is an interesting point: if a software company is selling their database for x then that is obviously what they think it is worth, isn't it? And if they are prepared to offer a discount, then why wasn't that the price in the first place?

So if you are buying a new CRM database for your charity then do keep a few things in mind if you expect or even get offered a discounted price:

1. Purchase time is the best time to get discounts, so if you expect to increase the number of your licenses later, bargain at that time!

Suppliers will often give discounts when you are actually buying their system, whereas once you are a client, it will be far harder for you to bargain at that time to get discounts on further licenses. So, if you know that even though you are going to start with n concurrent users but you feel you may well increase that number within, say, 6 to 12 months, then see if you can negotiate a discount on those additional licenses at the time of your purchase. You need to agree a timescale for when any such discount structure is valid – it’s not fair to expect a supplier to offer an open-ended deal on that.

2. If a supplier provides a discount on a previous quote, check you are still getting the same software and services

If you do get an initial quote and then, for whatever reason, the supplier offers you a second quote at a discounted amount, then the first thing you should do (unless you know you are getting a different proposal) is check with a fine toothcomb if you are getting exactly the same proposal as you did first time around – exactly the same software with the same licenses and modules, and exactly the same services with the same number of days, level of support staff and so on. And if so, great – that’s a proper and decent discount. But if not then go back and point that out to the supplier – a discount that has actually cut down on software or services isn’t a discount at all, it’s a revised quote for a different solution. Give them a chance to explain or make amends but if they won’t then you need to consider whether the new quote is really what you want. Don’t get hoodwinked!

One other thing to consider around discounts is if a supplier offers you a huge discount and it is pretty much for the same solution as they were previously proposing. Especially if they have done this unprompted because you have just told them that you don’t want their database. This may sound like a wonderful occurrence (!) but do take a few moments just to consider why they are doing that. Is there a genuine reason that they are offering you such a large discount or is there some desperation on their behalf?

I would suggest that you do consider carefully before you sit down with them again. I do know of instances where this has happened and it has worked because the supplier has been able to explain the commercial reasons for such a difference but in general I have found that clients are quite suspicious of such instances and even a little disgruntled. (Why didn’t they offer me that price in the first place? How much profit were they making originally?)  So just tread carefully, research other sales they have done, discuss it closely with the supplier. And if at the end of that you are not comfortable then walk away – it isn’t worth the risk; but if at that point you believe beyond any reasonable doubt that you really are getting a good deal from a good supplier then go for it!

3. Why and when should you expect a discount as a buyer?

Of course, there are very good reasons for suppliers to offer discounts: for a new supplier in the market, they may want to encourage early adoption - also helps justify the higher risk for you as a client; for a salesperson who is trying to meet their quota, there may be times when they are prepared to take a hit on the price; for competitive reasons to beat a signficant competitor for a significant bid; as a final piece of encouragement for you to sign before a given date; in recognition of entering a new sector for the supplier and so on. And of course, if the supplier normally sells to for-profit companies then they may give a discount to charities and nonprofits, which is obviously fair and great to have.

What I don't think is so valid for buyers to do is to just say, "Give us a discount and we'll be a reference site for you". I would hope that whatever the case, if the supplier ultimately does a good job, then you would consider being a reference site anyway.

I think discounts work well when, as a buyer, you have selected a preferred supplier but that supplier might have quoted a significantly higher cost than your second choice. In which case, it is perfectly fair to go back to your preferred supplier and ask them for a discount. Even then, depending on the cost difference, I wouldn't necessarily expect them to meet the cheaper supplier's quote - after all, they might cost more because they are better - but you could certainly expect some allowance to be made.

FaceTwitFlashSpace: A Personal Rant

There are one or two vendors at the moment who are saying some amazing things about their “fundraising software” (and yes, I have deliberately put those words in quotes) so that if you believe their hype then you would think that you could implement their systems more cheaply, more quickly and oh so much better then any of those old-hat fundraising databases that have been around for years; and you’d be completely mad not to buy them now. Now! Apparently time is up for the old guard because they just can’t offer our WonderfulNewFunction (and we’re so much simpler to use) or they don’t run on TheNextBigThing.com platform or they don’t integrate with FaceTwitFlashSpace – which everyone knows is where every nonprofit has to be these days because they are raising, um, some money on it…  And it’s starting to drive me up the wall a bit.

So, good charity folk, listen up. Do not buy a new database because a vendor tells you they are simpler/cheaper/easier. Do not buy a new database just because a vendor tells you that you must must must use the Cloud. And do not buy a new database simply because it has a link to 3 social networking tools.

Now, before my face turns red with anger and steam comes out of my ears, let me clarify one thing: I am a very much a fan of SAAS. I believe in Open Source. I really think the new, more ‘generic’ CRM systems will give the traditional fundraising package suppliers a run for their money. I do. But I am also very much a fan of fundraising packages. I believe that proprietary software can be good. And, guess what, I am fan of systems which do what nonprofits want them to do. I think that (most of) the guys that have been around for years and years and who are still providing fundraising software are here for a reason. They are not selling still simply because there are no other options. Some of the functionality you will find in the better, package solutions has had thousands and thousands of man hours of development over years of real time. A new kid on the block may be able to replicate some of that more quickly, which is great, really I think it is, but it’s also common business sense to realise that they maybe cannot do everything which a longer-standing supplier can in such a short space of time.

So what should you do? Well, buy a new database because it is the right system for you. And if it turns out that the best system for you is cloud-based then fantastic, you’ll get all the benefits of that. And the downsides. And if you end up hosting a Windows-based system on your own server – fantastic; you’ll get all the benefits of doing that. And the concerns and issues. And if it can’t integrate with FaceTwitEtc then how much does that matter? I mean really matter? Is your fundraising going to fall apart because you can’t do such integration? Or actually, more likely, is your fundraising going to fall apart because you can’t process income efficiently, you can’t segment your database in the way in which you really want to, you can’t support your major giving team, your events team, your DM and telemarketing teams. And you can’t analyse your data and use it to make the most informed decisions for your charity.

So do your system assessments based on your requirements and the benefits you will get. Of course technology will be part of that – the technology which is available now and that which will be in the future, which of course includes the web and social media. Of course, cost is important, very important, but it’s not just software cost, it is the Total Cost of Ownership, and that over (say) a 5 year period. And of course you should look at new options on the market – every now and then a new system will come along which really is fantastic and will, if not quite blow all the other systems out of the water, then they will certainly give them a damn good run for their money. But at the end of the day, you make procurement decisions based on the benefits the software will give you. It’s not one thing and it’s not that simple. And please, remember that your fundraising software has to still do all the fundamentals that you need it to do. Now.

Lessons Learned from Implementing Single Supporter Systems (Part 2)

This is the second part of a blog post on the lessons I've learned as a project manager, implementing single supporter systems at a number of charities over the last few years. You can see part one here if you haven't already read it.
 

Lesson 5: Four Technology Lessons

As I mentioned, the technology within your new system may be the simpler bit, but that doesn’t mean to say it is always simple! And, as per a common theme of this post, there are of course many, many technological lessons to learn from implementing Single Supporter Systems; but here are 4 key lessons:

i)                    Keep it Vanilla. Fundamentally, what this 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. There are just so many great benefits which you will get from doing this, such as: improving the simplicity of implementation, lower risk, a faster implementation, a lower cost implementation and much more. I have written a whole separate blog post on Keeping it Vanilla, so please do go read it if you want to learn more!

ii)                   Data Migration is tough, but it is just technology. Again, I have written a brief, separate post with my top 3 data migration lessons, but because you could be migrating data from multiple source systems into your new single system, it has to be something you take very seriously.

iii)                 Integration is tough. In fact, it can be the most difficult technology part of some Single Supporter Systems. Everything from database/web integration and integrating with third party software, through to integrating data feeds in from other sources (e.g. fulfilment houses, third party web sites) and passing data through to other systems (e.g. finance systems). So, my advice is start on these as early as possible in the project, get your supplier involved or a dedicated expert who can work on this, and see such integration as a specific work item within your implementation; i.e. do not treat it just as yet another task which has to be done. It is of course, but it is highly likely to be a much harder one.

iv)                 Implement reporting in the initial implementation. I have been part of projects where this has been done and where it has not been done, and there is no doubt that the better approach is where it was actioned. It is such an important part of the initial implementation and of having the system at all – after all, there is no point in having a database if you can’t get the data out! But, it is often easy to overlook or forget. I would even consider having the reporting requirements as a separate workstream within the project.

Lessons 6: You need a Project Manager

I’m hoping this is something I shouldn’t need to say, but just to make sure: you need a Project Manager. And unless your Single Supporter System is remarkably small, you need a dedicated Project Manager. Because your implementation will take time, effort, co-ordination, liaison with many interested people and parties and a heck of a lot of work; and it just isn’t possible to do that for any significant system without a dedicated individual.

For more thoughts, on this, read my post on the Top 10 Benefits of Project Management.

Lesson 7: Just because you now have a joined-up, Single Supporter CRM system, does not mean you can now do joined-up CRM.

So you have your completed Single Supporter System, which of course means you are ready to “do” centralised CRM, yes? Well, no. Because although your new system will of course give you the tools to manage your contacts centrally, it does not mean you are ready and have the processes and protocols in place to implement this.

It’s all about the Change Management.

The best example I can give is this: if previously, your different departments or teams were all writing to and emailing their contacts without worrying about what the other departments/teams were doing, then this won’t change automatically just because you have a new system. You will still need to literally sit down and discuss this and plan your communications and contact management strategy from a centralised point of view. And it won’t necessarily be easy!

So, again, plan ahead, plan separate Change Management streams within the project, recognising that the technology is the deliverer and driver and not the creator of answers. That is down to that good ol’ fashioned thing called human decision. Although of course we hope that the new system can support and implement such decisions – that would certainly be quite nice…

Lessons Learned from Implementing Single Supporter Systems (Part 1)

I have helped implement and been the project manager on a number of Single Supporter Systems over the last few years, and last week, I gave a presentation about some of the lessons I have learned from doing so at the Institute of Fundraising Technology Group conference. This post incorporates the details I discussed at that session plus a bit more. 

I have split the post into 2 parts because there is quite a lot to say, although as I mentioned at the conference, I can sum up my lessons learned thus: it’s the people and processes which are the difficult parts, the technology is the simpler bit. Although do note I said simpler, not simple…

Lesson 1: What is a Single Supporter System?

For the purposes of this blog, I am going to define a Single Supporter System as something which enables you to see everything about a defined set of constituents in one place. I use those words carefully as the actual system (the 'something') could be a single database or it might be a ‘marketing view’ of several source databases. I’m not going to go into the technical issues and the pros and cons of all such approaches in this post, but the heart of my lessons learned will be the same regardless of how you do it technically.

I also have a slight assumption that if you are building a Single Supporter System then you have, or have had multiple existing systems, or you may have one system but you are now implementing it with new and different departments or teams who have never used it before. That said, if you are planning a new CRM system which is just for one team, such as Fundraising, then most of these lessons will be equally applicable.

It is interesting that it can be difficult to define a Single Supporter System and there are many similar terms and words which we could use instead, all of which could be easily inter-changeable. For a bit of fun, click on this diagram and you will see what I mean! My favourite is “360 degree customer relationship management database”; that’s some TLA…

That said, there is also a serious point to mentioning all these buzzwords, because one lesson I have learned is that it is often better to give the system a more “user friendly” name than The Single Supporter System or the name of the software package you are using. A short, well-understood moniker can help users’ understanding and acceptance, especially if it is an organisation-wide database and not just in one department such as fundraising.

The other key point which you need to define immediately is that middle word in all these phrases: is it supporter, donor, contact etc. Again, this is important from a comprehension and acceptance point of view amongst all the users, but more critically, we have to define just what records are going to be stored on the system and which are not. That may sound obvious but if you do not define your scope right at the start of the project then you will heading down a long, dark path of confusion.

Lesson 2: Define a (Strong) Business Case

Following on from my last point, let’s take a step back. Not only do we need to define the make-up of the system but there are lots more things we need to define and agree on first. And for this, we need a Business Case – i.e. not just something we say, but a properly structured and well defined document.

There are many reasons why and it requires a whole separate blog post to discuss [and indeed at the IoF conference, there was a separate seminar examining this] but for me, and especially from my experience as a project manager, one of the key reasons for having a Business Case for a Single Supporter System is so that we can absolutely define the scope and benefits of the project; so that if, during the implementation, someone in the organisation says that their database should also be included in the new system, then, if it wasn’t in the original Business Case then I can very simply say that isn’t something we are doing. Or, if they really think it should be, then they can ask for the Business Case to be reviewed, and if that is agreed to, then, if the Business Case subsequently changes, then we can decide if the Business Case still holds water and thus if the project should still continue.

So my three key reasons for having a business case for such projects are:

-         To define the scope of contacts/records being held in the system (as discussed above);

-         To define the functionality;

-         To set the objectives and measurable benefits we are aiming to get from the system;

The Business Case also needs to have top level management support, the more senior the better.

A quick word on the fact I said the benefits should be measurable. I know this is difficult but we have to do it. If we don't then how can we truly say if a project is successful or if it has reached the goals and benefits it set out to achieve.

Please note that there are many more reasons for having a Business Case and many other things which should be included in a Business Case – this post is just to emphasise the key ones I think are useful for a Single Supporter System. For a very interesting discussion on this very point, have a look at the IoF Technology Group’s LinkedIn Group discussion board.

Lesson 3: Manage User Engagement

So if I think that the people are the harder aspect of implementing such systems, then what can we do to manage user engagement?

I have actually written several other blog posts about this, so I am going to sign-post to them here:

-         16 Ways to Improve User Buy-in, and

-         The Next Time Someone Says, But They’re My Records…

I do want to emphasise the second post. Because when it comes to Single Supporter Systems, we cannot afford for individuals to be maintaining their own data silos (typically, spreadsheets…). They may well have good reasons for wanting to ensure they control communication to their contacts (e.g. VIPs, major donors, MPs etc) but this does not mean they should not store their data centrally. The fundamental reason being that if they don't store their contacts on the central database then, in actual fact, it will be impossible for them to stop anyone else contacting them - assuming that such contacts have - or will have - other relationships with your organisation which are already stored on the central database. In addition, more and more, organisations are understanding that the concept of "my records" is not helping the charity holistically – and the end of the day, it is the organisation’s data, not yours.

Lesson 4: We need to Define our Business Processes

This is a classic, now quite old “cartoon” which shows the evolvement of IT practises. Click on it and have a look if you have never seen it before! It is frighteningly accurate too many times!

And it emphasises an important point: it isn’t easy defining business processes but it is necessary in order to implement a new system – especially a Single Supporter System where it is imperative that everyone uses the system in the same way. It is also very hard sometimes for users to sign-off processes when they are written-up and given back to them, especially if/when they are written up in “tech speak” and/or “system-specific speak” even if the document detailing the processes tries not to be technical. We have to recognise this and need to work very hard to make such documents as understandable as possible to such users. I have also found that mocking-up the system to actually show users how it will look can help this process.

We also have to remember that a new system gives us the chance to ask the question, “Why do we do the following process as we do now anyway…?” And in my experience, it is likely that the answer will fall into one of 3 categories:

i)                    We investigated and it is the best way of doing the process;

ii)                   Er, dunno, we’ve just always done it that way…;

iii)                 Because our existing computer system made us do it that way.

A new system is thus a great catalyst for us to address the above and decide on what is the best approach for the new system. And over the years, I have come round to thinking that the following works best: you should, where possible, fit your business processes around the database you buy – and not fit the database around your processes. This does presume that you are implementing a package of some sort and not creating a bespoke solution.

Why? Many reasons again, but the key benefits are:

-         The database has been designed (hopefully) using good practise and has evolved over the years for many other organisations to use, so why can’t you use it that way too?

-         You’ve bought the software, so use it! If you decide to start customising and changing it left, right and centre then is it the right system anyway?

-         It is more future-proofed; when new releases come out, there are no customisations to break, no bespoke practises to change.

-         It is (usually) cheaper and quicker to change your processes than the software. Usually…

-         And, for Single Supporter Systems, you are likely to have many different views from lots of different people as to how we should be doing something; so having a base of ‘this is how we do it’ can be useful.

I also realise that rules are there to be broken so although the above is always my opening gambit, it does not mean you should always follow this rigidly. I recognise that there are some business processes which really have to follow certain processes (e.g. batch entry, gift aid processing) but I have to presume at this point that your initial procurement was good enough to have ensured that such important processes could be done as you needed them to be. So, if you haven’t done your procurement yet and you are reading this, then take note!

Part 2 of this post will cover the following areas: Technology,  Project Management and a final key point which brings it altogether.

How to Interview and Employ a Great Database Manager

I am publishing today a free eBook called "How to Interview and Employ a Great Database Manager". But I am using the "pay with a tweet" concept for the first time so my thanks in advance for helping me try that out! Just click on the following button to download - don't worry, it only takes a few seconds.



About the Book

I have helped a number of charities interview and employ new Database Managers. The first time I did it, two things hit me: first, I was quite surprised at how I, as a “database person”, really could tell if someone else was also a “database person”. I found that if I asked the right questions, dug a bit deeper where necessary and gave an interviewee a chance to express themselves, then I could soon tell if someone did have the experience or the potential to be a Database Manager.

The second thing I learned straight away was that just because someone has the skills to be a Database Manager, it doesn’t mean they will necessarily fit in with your team or your organisation. In fact, the very first time I helped a charity with their interviews, after the first candidate which I liked, the Development Director told me that it didn’t matter how good that individual was, they simply wouldn’t work well with his team.

So, everything I discuss in this book has that significant caveat to it: I will try to show you what a great Database Manager looks like and how you might be able to employ one, but everything else which you would normally do when interviewing anyone for any post – from sifting through resumes and CVs through to agreeing a salary which your charity can afford - still holds just as true as ever!


Who this Book is Intended For

This book is intended for people who work for charities who need to employ a database manager. You could be an existing Database Manager looking for an assistant, a Fundraising or Membership Manager who needs someone to look after their database, or an Operations Manager who needs a new Database Manager and so on.

You do not need to be a technical person to apply many of the ideas in the book, although there is no point in denying that it might well be difficult for you to fully decide if someone is a good Database Manager if you cannot understand some of their slightly more technical responses to your interview questions. In which case, having someone on hand who can offer advise on that can be a great help; very often, the outgoing incumbent can be an option or someone from your IT staff; and I know other charities who have used trustees, other technical staff from their charity, or a manager from another charity even; and of course consultants like myself can help with the whole process.

Because I am writing it for charities and nonprofit organisations, there is a slant in some parts of the book towards fundraising and membership because such areas are so central to nonprofit organisations. But you should be able to use it just as successfully for any Database Manager you want to employ in your charity.

I hope you find it useful.


To download the book...

... Just click on the following button; don't worry, it only takes a few seconds:

9 Guaranteed Ways to Improve the Use of Your Database : Part 2

This is the second part of my blog on guaranteed (really!) ways to improve the use of your database. (But please do refer to my first part for a couple of caveats on the Ease, Time and Cost points...)

6. Instigate a structured training (and learning) culture

One of the most common complaints from end-users of CRM systems is that they have not received sufficient training. The training may have come from the person who’s job they were replacing, it may have come from someone else entirely who knows a bit about the system, it may come from someone who has been at the charity for years and is still following processes which are way out of date. Or they may have just been given an old, dog-eared collection of papers and told that is the user manual – or they may not have had any training at all!

If you want your database to be better then you need people to use it as it is intended. And therefore you need to train them. Properly. By people who know what the database should be doing, who know what the latest processes are, who have the time to train someone, who are happy and comfortable training someone - and, of course, training someone who has the time and inclination to learn. Being trained on your organisation’s database should be part of someone’s induction plan when they join your charity.

I also distinguish between a 'training' and a 'learning' culture: individuals should be encouraged to learn more about the system(s) they are using. This isn’t necessarily easy! Why should they bother learning something or asking more about something or wanting to improve something if it doesn’t help them with their job? So make it so that such practise does help them with their job. If they can’t do something on the database then encourage them not to remain quiet but to tell someone. If they have a good idea then get them to tell someone. The more people learn about what is possible on a database then the more they, you and the organisation will get out of it.

Ease: No technical skills, but needs Senior Management support

Time: On-going

Cost: Free

7. Create reports (and dashboards) your users and managers really want

If you really want to improve the use of your database, then you need to give users and managers information which they really want. So ask them what information they want, ask them what would really help them in their every-day role and with their strategic role, ask them what is most important to them and what they have always wanted to know! You might want to “manage expectations” around this by explaining that you might not give them what they want tomorrow... but you will try! You might also find that they can’t get such reports because no-one is collecting the data they want. So they can then help you rectify that.

Then create reports which they can use. And dashboards – managers love dashboards.

Ease: Needs technical skills

Time: Each report might take from a day to many days!

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

8. Create a Business Analyst role

This is one of the best ways you can get more out of your data and database, but it is also one of the more expensive. Human Resources always is. But what a Business Analyst (BA) will bring you to your organisation, if you don’t akready have one, might change and improve the way you do things so that they will more than pay back their salary.

Because what a good BA can do is go out to the users and discuss their needs, ask the managers what information they want, examine the procedures and processes you have, work on strategic documents with your staff, analyse data, analyse the database, produce options for change, make recommendations and help implement. They can act as the “bridge” between your database team and your users.

I realise this might sound like some “impossible creature” to some people, but really, they can be one of the most important roles in any organisation. To have someone who understands data and databases and what they can and can’t do, but can talk to your users and understand their business is gold-dust. If you find someone who can do this for you, hang on to them!

I should also say that although I use the term "Business Analyst" and define it here as a specific role, if you have someone who can do this sort of work even if they are formally called the "Database Manager" or any other similar position, then that is just as valuable. It's the skills and process which are important, not the job title per se.

Ease: Can be quite difficult to find someone good

Time: Permanent role

Cost: Expensive, as in you need a full-time employee on a reasonable salary

9. Get rid of any Data Ownership hang-ups

I’ve blogged about this before, so to summarise here:

Many charities are now moving away from "data silos" and the concept of "owning one's records". Which is great news and about time. So the next time one of your users/colleagues/staff says to you, "I don’t want my contacts to be stored on a central database because I don't want anyone else to be able to contact them…" then this is the response I recommend you give them:

The fundamental problem with this is that if they don't store their contacts on the central database (and instead, for example, keep them stored in Excel) then, in actual fact, it will be impossible for them to stop anyone else contacting them - assuming that such contacts have - or will have - other relationships with your organisation which are already stored on the central database. For example, if your user is the events manager, then if any of their event registrants are also donors, volunteers, prospects, on other mailing lists etc and as such they are already stored on the central database, then how can the events manager stop them being mailed? No-one using the central database will know that they are also on the separate events spreadsheet. Moreover, they will probably need to be contacted sometimes by other users anyway.

And anyway, it isn’t “my data”, it is the charity’s data. Start using it for the holistic benefit of the charity.

Ease: In theory easy, but you get stubborn individuals!

Time: Instant to instigate, may take time for everyone to buy-in

Cost: Free

I hope you find all these suggestions useful. They really will improve your database if you put them into practise in a structured and considered way.

And if you have any other suggestions then by all means leave a comment below.

9 Guaranteed Ways to Improve the Use of Your Database

Each of the following processes will improve the use of your database - really! Some are simpler than others, some are free and some definitely require investment, some require technical skills and some just need a new business approach. But they are guaranteed to bring you benefits if you don't already follow such practises or you haven't implemented such functionality. And you can quote me on that!

I have also tried to indicate for each one how easy it is, how long it would take and how much it would cost. Please bear in mind these will of course vary depending on your specific requirements, your database, your in-house skills and so on. So don't quote me on those figures quite so much...

I have split the blog into 2 posts, so ideas 6-9 will follow in a separate posting.


1. Clean your data (and do a data audit)

It doesn’t matter if you have the best database software in the world – if your data is rubbish then you won’t be able to use the database efficiently. End of story. Because if you have records without key data, incomplete addresses, blank fields where they shouldn’t be blank, duplicate records, inconsistent data in the same field, different use of the same field, if you can’t store specific data items which your users need, unreliable data and so on and so on, then how can your users trust the database, how can they produce reports or do queries or segment the system properly or base decisions on correct data, plan their strategies and do their every day work.

So clean your data. Ideally, do a data audit: create a report which shows the different areas of your database, what fields you have, the type of data, record counts, counts on data items in key fields, data integrity issues and so on. Then you can plan your data cleaning exercise properly and in a structured way.

Ease: Not too difficult

Time: Audit: 1-2 weeks. Data Clean: several weeks upwards

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

2. Add data integrity rules

Following on from (1), we need to keep our data clean and one of the best ways to do that is at the point of data entry, and one of the best ways to help enforce good practise for data entry is to implement data integrity rules into the database. So, for example:

• Ensure that a drop-down table (a.k.a. look-up or reference table) is used on fields which have a set or finite number of options within their data set. E.g. Counties, ethnicity, appeal code, type of interaction. (And don’t let end-users add their own codes to such tables!)
• Make fields “Required” where they must have data recorded in them (e.g. an individual’s last name, a specific code). But bear in mind that if you do that, then there must be an option for all possibilities. E.g. if you make Post Code required then what does a user add if they really don’t know a contact’s post code?
• Use defaults. For fields where there can be a default, add one. Users can over-write if appropriate.
• Manage rules on date fields; e.g. don’t let dates get added which are after today’s date where this shouldn’t happen; e.g. date of birth.
• Use calculated fields. e.g. Automatically calculate age based on date of birth, as opposed to asking a user to key that data.
• Automatically populate fields based on other fields: e.g. gender based on title (where possible), cost centre based on fund designation.
• Properise fields where possible and appropriate; i.e. with an initial capital letter. e.g. First Name.

And run “data integrity checks” against your database at regular periods. So where it isn’t possible to create a simple rule on a specific field, create a query/report whereby you can at least produce lists of any data anomalies. For example, appeal codes which shouldn’t be on specific record types, individuals marked as deceased who are still giving donations, UK counties on a record with a foreign country.

Ease: Often needs technical skills

Time:  From a few days to on-going

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

3. Don't allow people to use any spreadsheets instead of your database

If you have a database which your staff should be using then don’t allow them to use spreadsheets instead. As soon as the first, external spreadsheet is created, then the data integrity between the two will be lost. Data updates won’t be done, your other users won’t know about specific information now stored on that spreadsheet, you can’t keep tabs of communications with the people on the spreadsheet, there is no security on the spreadsheets etc.

Keep all data which should be on your database on your database. You may need to get a central message from senior management to help you enforce this but it will all be worthwhile.

Ease: Easy to start! (Can be harder to enforce...)

Time:  Immediate... but then on-goin

Cost: Free

4. Automate what isn't automated

This will always help your database, whether it is for the database team or the end-users. If you can automate something then it will be quicker, more efficient, more accurate, more timely and really optimise what a database is for.

For example: Gift aid claims, reports, mailings, acknowledgement letters, exports to fulfillment houses, importing data from fulfillment houses, extracting data for your finance system.

Ease: Need technical skills

Time: Depends on task but each will probably take time

Cost: Free if you can do it internally (Otherwise you'll need to pay someone)

5. Integrate it with your web site

If you take online donations, accept online event registrations, let people sign-for newsletters or if you would like to let your supporters update their own address and contact details, opt-in/out to specific communications etc, then you need to update your fundraising/CRM database in one way or another with such data. If you do it manually at the moment then the time and effort is likely to be pretty high.

Integrating your database with your web site so that this can be automated in one way or another will bring great benefits. But it isn’t the simplest thing to do from a technical point of view, nor the cheapest. And you’ll need input and co-operation between different teams so it may not be the easiest in that way either and may take some time.

But if you can automate such integration then you will save so much time and effort internally and add some great data capture, so that the benefits you can get from doing so may well outweigh the cost.

Ease: Often difficult

Time: Allow several months from start to finish

Cost: Potentially high

In the next post, I will consider training, reporting and the benefits you can get from a business analyst.

Fundraising Software for arts organisations: Software Options

In part one of this blog, I considered if Arts Organisations needed a different approach to incorporating and using fundraising software compared to “classic” charities. If you haven’t read that post then I would encourage you to do so now – this second post will still make sense without doing so but you’ll get more understanding of my thoughts behind some of it if you do read it.

What are the Pros and Cons of an Integrated Database for Arts Organisations?

This may sound like a slightly stupid question – I mean, what could be the downside of having a single system?! And isn’t it obvious why a single system is better?

First, the benefits:

• All contacts are in one, single database. Fantastic! And this of course is the core benefit. You don’t have to transfer data between systems (and no matter what anyone tells you, that does take time, technical knowledge and money), you don’t have to ask someone else to check if a donor is already on the membership database. All your staff can access all the key data about each contact – it is easy to look someone up and find out their relationship and history with your organisation.
• You will avoid the embarrassment of one of your staff contacting a prospect for £50 when someone else is about to ask them for £50,000 (etc). You can manage all your data protection needs, opt-in/outs, mailing preferences et al all in one place.
• Your staff will only have to learn the user interface of one system. Very nice benefit.
• You can do cross-marketing far more easily. With all contacts in one system, you can analyse, segment, target and contact groups of people far more easily than you can do if you have the records in different systems. You can of course extract records from multiple systems into one “marketing database” but that still requires time, effort, usually a fair degree of technical nous and the ever-recurring need to identify duplicate records across the systems.
• And thus, you have the foundations for an achievable, central contact strategy – a real “CRM” strategy. That’s amazing.
• With a few exceptions, most of the suppliers of these sort of systems are not the large (sometimes multi-national) companies which can be found in the charity sector. So if you are not a large arts organisation, then if you buy an integrated database from a mid-size supplier, you may well have a closer relationship with them. (And before all the large suppliers scream, I know this isn’t always the case! But I do know that some small-mid size arts organisations I have worked with like the smaller suppliers. Plus, read my final downside below…)

But, there are possible downsides:

• I still have yet to see an Integrated Database for an Arts Organisation where the functionality, ease-of-use, reporting and so on is equal to or better than the functionality, ease-of-use, reporting and so on in the best, stand-alone fundraising, membership, ticketing, event or CRM systems. And this is therefore probably the biggest decision you need to make: do you accept that you may not get all the wonderful and highly sophisticated features which you would find in a dedicated fundraising database and you may not get the beautiful interface of some of the online CRM/event software systems – but you will get a single system with all your data in one place. This, I believe, sadly, is the compromise. (Suppliers – you are welcome to challenge me on this! And I would love to be proved wrong! But at the moment, that is my belief and experience).
• Change Management. Implementing an organisation-wide system requires a serious and structured approach to change management in the organisation. Do not under-estimate that! It will force people to think about things they have never had to think about before because, before, they only had their team to worry about. Don’t forget this.
• Security. If you have a single system, then you might find that there is some data on some records which some staff should not have access to. Some systems will be able to manage that, but not all.
• You may need a Database Manager. Ironically, if you have previously had separate systems, then you may not have needed a person in your organisation to act as the “database manager”. A single system will almost certainly mean you do need such a role. Not necessarily a technical person, but someone who can centralise data integrity rules, add codes to look-up tables, create policies and procedures, understand the more complex parts of the database for “cross-marketing” etc, and be the “go to” person for all the other staff for when they forget how to do something or want to know how to set-up a new event or campaign.
• There may be other costs you didn’t have before. E.g. does the new system require a larger, dedicated server? Does it require additional, third-party software? Will you have to re-vamp your web site?
• With a few exceptions, most of the suppliers of these sort of systems are not the large companies which can be found in the charity sector... So you may run the risk that a small supplier will go out of business or cannot invest enough to create newer systems for newer technology as that comes along.

And what about a Stand-alone Fundraising Package?

Not surprisingly, the pros and cons of dedicated fundraising databases are primarily the opposite of above. There are some great, extremely sophisticated fundraising software databases available and you should be able to do all your development on them. They of course vary a great deal in price, functionality and quality, but they do come in all sizes and price ranges from £100 upwards. (See more below on the Resource Listings). And it is “simpler” to buy in that you only have to worry about one team, one set of requirements, one budget etc.

But of course if you implement a dedicated fundraising package (or any other stand-alone database within your operations) then it will primarily only provide benefits to that department. If one of your prospects or donors is also on the box office system or email list held on the web database, then you will only know if you look or try to synchronise data between systems. And you can’t stop someone else in the organisation from contacting your key prospects because if a prospect happens to “enter” your organisation through a different route, then your other staff cannot always be expected to ask you every time they meet someone if they are an important prospect or donor.

Of course, this is not a problem unique to the arts but, as I mentioned before, because of the likelihood of multiple operational databases existing in an arts organisation, it tends to be more common and the problem more pronounced.


So Should You Buy an Integrated Database?

I personally believe in single, central databases. Not just for arts organisations, but for all not-for-profits.  I think the benefits usually outweigh the downsides. And if you have the option, then I would always at least consider this possibility.

As I say above, you may well need to compromise on some functionality, some ‘look and feel’ or some ease of use. But if you can do this then, as I say, at least consider them.

And if you find one which is right for you then that’s great. If not, then at least you looked. And if you cannot compromise on a specific requirement and you don’t think that any integrated system can meet your needs then of course you shouldn’t necessarily buy one. I am not saying buy a single system above all other considerations. But do look.


Resource Listings

• UK Integrated database software for arts and cultural organisations: www.itforcharities.co.uk/artssw.htm
• UK Box Office Software: www.itforcharities.co.uk/boxoffic.htm
• US Ticketing Software: www.technologyinthearts.org/?page_id=474
• UK Fundraising Databases: www.itforcharities.co.uk/fundrais.htm

In addition, for very small arts organisations who really do just want a simple, low-cost fundraising or membership database, then the following are options as well:

• KISS Software Solutions: www.kissoftwaresolutions.com  Lots of fundraising functionality, membership too, but slightly aging interface; but for £100 you can’t even make a database more cheaply in Access.
• ITSorted (ContactLink): www.itsorted.org.uk £400 upwards. More for membership and events but lots of nice additional features too.
• Ravensdowne: www.ravensdowne-software.co.uk/membership/membership-software.aspx £295 upwards. Membership software.

And because they offer an alternative approach to the traditional packages listed above, some organisations might also find it useful to consider a “generic” CRM solution, especially as they are being implemented by the not-for-profit sector more and more and with increasing support from suppliers specialising in providing “templated solutions” for fundraising and membership requirements. Note that the real costs for these systems comes more in the implementation than the software.

• CiviCRM: http://civicrm.org/ Open Source constituent relationship management system with membership, event management and more. Great system but probably not for the beginner in terms of set-up.
• Salesforce: www.salesforce.com/uk/ Salesforce is a “generic” CRM system which is gaining plenty of users in the NFP sector because it is free for the first 10 licenses and reduced pricing thereafter. And it is web-based so lots of benefits from that.
• Microsoft CRM: http://crm.dynamics.com/en-gb/ MS CRM is also a “generic” CRM system, and again with lots of NFP users. Cheap Microsoft pricing for charities.

A Final Note to Suppliers

If any suppliers want to add Comments below on any of the above then by all means please do so. All constructive comments are welcome (and a link to your site is fine) – any blatant sales pitches will be removed!