Nine Costs to Remember when procuring CRM Systems

On the ninth day of Christmas, my truelove gave to me... Nine Costs to Remember when procuring CRM Systems

There are many costs which you need to take into account when procuring and then implementing a new CRM System or Fundraising Database. The following are the core costs:

• Software Licenses: Regardless of the type of license - perpetual vs monthly/annual (subscription) licenses, and concurrent vs named vs unlimited user numbers - you need to make sure you are comparing like-for-like across all your potential options, including any 'core module', additional modules/apps etc. (And that's before you consider and compare actual functionality and benefits.)
• Hosting/Storage: This can be different depending on whether you are looking at cloud or on-premise or third-party hosting. It is comparatively simple to cost at an "explicit" level but can be very difficult when looking more deeply. At a simple level, Cloud systems will probably include x Gb of storage with your standard price and then you pay extra for every additional Gb you need. Bear in mind that can add up, especially for larger databases. You will therefore need to work with potential CRM suppliers to calculate how much storage you will need - and then add more to allow for future growth. That can be difficult. With on-premise solutions, the explicit cost is of course the hardware and associated software - but the harder costs are the fact that your internal IT staff will need to maintain that hardware, do upgrades etc, which is why Cloud salespeople say Cloud is so much cheaper. And for on-premise, you should probably also allow for the cost of new servers every n years, depending on your organisation's policy.
• Internal Project Team: Except for small database implementations, you will almost certainly need specific costs for an internal project team, back-filling etc. (See Christmas Tip #6 for a few more thoughts on this). Such costs could vary depending on the type of software or supplier you select.
• Supplier Professional Services. This has the potential to be a wide range of costs - and one of the highest budgets. For example: consultancy, system design, development and customisation, creating blueprints, report writing, installation, support with UAT, post-live support, project management etc etc. Read another blog post of mine about how you can compare suppliers' professional services costs and what to look out for.
• Data migration: I have separated these from the rest of the Supplier Professional Services because, for any database larger than a simple spreadsheet, they can be harder to cost up-front, until a supplier has had the chance to look at your existing database in detail. For larger projects, this won't come cheap - do not under-estimate.
• Training costs: whether it is internal, using a third-party/contract trainer or using the supplier's staff.
• Integration: If your project involves integration of any sort (and it almost certainly will if it is for fundraising), from receiving online donations on your own website or data from JustGiving, through to importing data from fulfilment houses and exporting to finance systems - and more - then these costs can start to add up. I have written several posts specifically about integration over the years. Bear in mind 'integration' can mean different things to different people and to different suppliers so be careful when comparing costs and approaches. Talk to all suppliers in detail to clarify any uncertainties.
• Annual (on-going) Costs: Software Support/Maintenance - Most traditional fundraising package suppliers charge x% per year for software support/maintenance but that often includes future upgrades too. With CRM systems, the business partners you implement the software with will also likely charge annual support costs which will vary depending on whether they are selling a 'template' solution, developing from 'vanilla' etc. And Software licenses - if you are paying on a monthly/annual basis then you will of course continue to pay such costs every year. To compare, annualise them and compare over n years.
• Other Costs: Okay, I know this category could include anything but that's the point! I do also want to emphasise that there are any number of other, additional potential costs in a fundraising or CRM implementation, from hardware and workstations, to PAF and banking validation software, other people costs, paying fulfilment houses and other suppliers to change file formats and so on and so on. Find what you need and build them in to your final budget.

Six roles you need in your CRM project team

On the sixth day of Christmas, my truelove gave to me... A list of 6 roles needed in larger CRM Implementations

For larger CRM implementations in particular, the following are six roles which would be very useful. Some of them might not needed immediately when a project kicks-off, but they will be required thereafter.

• Project Manager: A good project manager is central to the success of a CRM implementation. They run the project day-to-day and deliver the project, hopefully within the budget and timescales and of the quality required and, importantly, act as the central communication hub to all stakeholders and interested parties.
• Solution Architect: This is a role which is becoming more and more important when you are implementing a Salesforce/Dynamics type project where the system design is so crucial. For such projects you should have your own in-house solution architect. They will translate user/business requirements into the (data) architecture for the CRM system at a technical level, and quite likely work alongside your supplier's solution architect.
• Business Analyst(s): They will work with your users and Subject Matter Experts (SMEs), extract their business requirements, document them and quite possibly create business/data flows of the processes. They are essential so that you can identify all your needs and processes and will be extremely helpful when it comes to implementing the new CRM.
• Data Migration manager: Although this might depend on who is doing the data migration (from the old to the new system) and how it will be done, at the very least you will need a person in your own organisation who really understands the in-depth detail of the existing database so that they can work with the new supplier. At the other extreme, it might be that they need to be even more hands-on in terms of mapping and migrating the data into the new CRM system.
• Test Manager: Regardless of your project methodology, you will need to test the build of your new CRM system, the data migration, work with your users and so on. A Test Manager to manage and co-ordinate all this will be invaluable.
• Trainer: Someone to train your staff on the new system. The best trainers I have worked with also understand 'the business' and don't just train in a 'press that button' style, but relate the new software to the users' needs and processes. They might even have some BA skills.

There are of course other roles such as in-house developers, product manager/solution owner, change manager, report writer, project support staff and so on.

Five Golden Things Which Underlie CRM Systems

On the fifth day of Christmas, my truelove gave to me... 5 Golden Rules (which are not about the software)

Whenever an organisation is reviewing or implementing a database, it is important to understand that it is not just the CRM software/the database which needs to be considered. There are at least five other key factors which influence any CRM system.

• Strategy - i.e. your fundraising strategy, management structure, communication strategy etc. This may sound obvious but if your fundamental strategy for fundraising, your communication policies, your IT strategy, even your management structure is not well structured then how can you expect your database to support your requirements. This underlies all aspects of CRM and indeed most technology projects. (And trust me, I have consulted at one or two organisations where some of the above were definitely not in place).
• Data: The best CRM system in the world will not be efficient for your use if your data is not up to scratch. You need to consider what data you are recording, how you capture it, data quality issues, data consistency, data integrity across fields and tables and so on. (There are plenty of other posts on this blog about data if you want to read more). Of course, any CRM software needs to be able to store the data you want and manage it well, but these days that should be the case with most contemporary solutions.
• Processes: When reviewing/implementing a new fundraising or CRM system, you should review your business processes. In my experience, there are three reasons that any process linked to your CRM software exists:
1. No-one knows why they are as they are, it is just done that way because it is..; or:
2. Because your current computer software makes you do it this way; or:
3. Because you have thought about it carefully and your current process is the most efficient way to do things. 
• Sadly, as much as I wish it was, the third option above is rarely what I find when I talk to charities. So: before you blame any poor database for the situation you might be in with it, have a look at your business processes and decide if they really are setup as best they could be, or whether there is room for improvement. I would bet there is.

• People: Are your staff trained on how to use the software? Who by? How is a new starter shown what to do? Do you have enough and the correct database support staff? And if you are going to buy a brand new CRM system, then be aware that your current database staff structure might not necessarily be what you need going forward.

All the above are, in my opinion, more important than the software/CRM system itself. i.e. You can have the best software but if you have rubbish data, if your staff aren't trained and supported, if your business processes have not been thought through, then you will find it difficult to get the most out of your CRM system.

• I also used to say the same about the final, fifth factor: your IT infrastructure. I would describe how if your server was too old and under-powered, if your internet connection was too slow, then again, your CRM software would suffer. And of course that is still true. But with hardware being so much more affordable and powerful now, with Cloud systems and access to the cloud so much more robust, I hope that this is now rarely such an issue. Of course, it is still important and it can still mean that good software will not work so well, but it is one of those things - given the correct budget - that should be more manageable.

If all this sound obvious to you then that's great, I'm delighted. But if you are finding that your current CRM system is not doing what you want, or you are looking at buying a new system then do bear all this in mind.

Why Do we still need so much training for Fundraising and CRM systems?

 

Over the years, there have been many promises about how we would need less and less training on our new fundraising and CRM systems, but in my experience, most new database implementations still require a fair amount of training. So why is that?

(First things first: there are whole books and thesis written about the best way to provide training on IT systems, so I have considered this blog post for just a few top level points - if you want to dig down further into the area then there is plenty more reading out there.)

We do have to remember that a fundraising or CRM database is not like a word processor or smartphone app. Fundraising/CRM systems are sophisticated and large applications, and, critically, they are also at the heart of our business operations and all our processes. So whatever we are implementing, they are going to take more time to learn than other software systems.

Secondly, because these systems are so sophisticated, flexible and broad-ranging, the administrators and database managers are going to require in-depth training and that isn't going to take a short time. There will almost certainly be multiple days training for such people.

And then we have the 'end-users'. Clearly this is where the bulk of the training needs to happen. And this is the area where we might be able to fine-tune and streamline some training courses for these people. Many vendors and organisations have moved on from the 'day 1, day 2, how to use our system' type training, and are realising that training the users around their particular business processes and specific instance of the system is a better way to do it. However, except for the very simplest of needs, even that is going to require a bit of time. And, as I said before, because in effect we are not just training on the software but reviewing the business processes too, and the users are having to understand how they have been impacted with the new system, then all that will add-up.

Which is why there is still so much training needed for most implementations of fundraising and CRM systems!

And a final word on some vendors: if you get a software supplier who tells you that you/your users don't need any training "because the system is so simple/intuitive…", then take that with a pinch of salt. If that's the case then not only must the software be so simple to use that anyone can start to use it without any problems or asking any questions, but they clearly also know all the new processes without any training either. Sorry - I can't see that happening.

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.

5 Innovative Challenges for Your Database Team for 2011

If you manage a database team, or you are part of a database team at a charity, then why not challenge yourself this year and do something a bit different and innovative! The suggestions below will take time and commitment and maybe even some financial input, but I believe that you and your organisation would get excellent benefits out of them (and slightly different from the norm). They are probably best suited to charities who have a bit of manpower in their database team and a reasonable sized user-base, but even if your organisation doesn’t fit that model then you could still adapt them to your own structure.

And even if you don’t like my suggestions, what about thinking of alternative but new and different challenges of your own? Share any you come up with in the Comments section below this post.

Enjoy!


5 innovative challenges for your database team

1) Hold an Internal User Conference. i.e. In the same way that your database supplier might hold an annual conference for their customers. Put aside a day (or a half day if a whole day is too much) and have a couple of 'streams' of seminars, invite users to speak at some sessions, invite a keynote speaker (try your supplier, ask a funder, invite me!), consider workshops or one-to-one "consultancy sessions" and of course put aside time for coffee and networking. Yes it will definitely take some serious organisation, yes it could cost to do it and yes it could be a challenge to get managers to let all your users go, but, hey, it wouldn't be a challenge otherwise!

2) Spend a day in a data/database department at a commercial organisation, learning what they do and how they practise database management. We can be very insular in the charity sector, and although I know plenty of NFPs who run wonderfully good database teams, we could definitely learn from for-profit companies too. Ask your fundraisers if any of their contacts, sponsors, funders etc might be up for helping, or just use your own contacts – we all have friends who work in large companies and other sectors. One thing you could consider is not simply selecting a company “similar” to your charity, i.e. a bank or a retail organisation. Why not try somewhere completely different? A leisure centre, a construction company, a vet! Surely we can learn something from other such industries. And if you have a large enough database team, send different people to companies in different sectors and then compare notes.

3) Think of new ways to use all the data fields which you already store in your database. I have done this a few times (admittedly with varying degrees of success!) but it’s always interesting, even if it’s just as an ice-breaker for a meeting. For example, why do we store an individual's first name? Just so we can write to them? Boring! Think of something else. How else could we benefit from knowing someone’s first name? How could we use that data/information? And what about your other fields - Date of birth? A job title, zip code/postcode, first gift date etc etc. Brainstorm. Who knows what it could lead to.

4) Dedupe your entire database, just for once! Now that would be a challenge… Can we ever say that we have no dupes in our database?!

5) Do some brand new data analysis on areas never looked at before on your database. So often, database teams are asked to do specific data analysis by fundraisers because of specific campaigns, or because we/they know (or we think we know) that tried and tested analysis techniques work. Which is fine and should of course be followed. But try instead, for example, to test whether there is any correlation between 2 or more factors/data items on your database which your fundraisers have never thought of using/comparing. Compare fields and data against each other, against time, against demographics, income and so on. This might well involve a lot of data mining to come up with anything new and useful, but if you do find something then that might create a whole new fundraising opportunity or income stream. Fundraisers are not data or database experts – you are; so don’t rely on just being reactive to their requests, be pro-active and think of some ideas yourself.

The Raiser's Edge: Why does one person like it and the next hate it?

I have recently been talking to several charities who use The Raiser's Edge. And it seems to me that whenever you gather together a group of fundraisers, throw in a few charity DBAs (and a pinch of technology consultants), and start talking about The Raiser's Edge, then, almost inevitably, some of the group will sing its praises and others will slate it and tell you it’s rubbish. But why? It’s the same software being used at the different charities (possible version differences aside), with the same functionality (modules aside) and surely all organisations could use it the same way? So why then, if one person loves it, does the next person find it just doesn’t work for their charity.

At this point, I should offer a clarification and a caveat on this blog post: To clarify, I have used The Raiser’s Edge in the title of this blog because it is used so widely in the sector and thus you inevitably get more people discussing it and therefore liking and disliking it. It is one of the more long-standing products on the market and fundraisers have inevitably heard of it. However, most of the points in this article could equally apply to any other similar fundraising, membership or CRM database package.

Secondly, the caveat is that such a question cannot be answered truly comprehensively in a brief blog post. Each of the points below could justify their own post (or set of posts!) and far more discussion. And of course there can be specific reasons why a database does not work for a specific charity. But because I am asked this or similar questions regularly, and because I really want to encourage charities to consider and understand the fundamental issues so they don’t immediately blame Blackbaud or similar suppliers, I hope this initial post will provide a fair and useful overview and supply the start of the answer.

So here are a few suggestions as to why we love to love or have to hate The Raiser's Edge:

• Data. I have been fortunate to have done quite a few data audits of Raiser’s Edge installations and the data in the system is one of the most important factors in the success of its implementation. Data Quality (accuracy, integrity, consistency, use of look-up tables etc) is key, the data needs to be up-to-date (a classic hate for fundraisers), the breadth of data (or lack of it) within constituent records affects data quality, as does the relevance of data and the trust which fundraisers put in the data which is stored on the database – all these are vital components. Too often I hear words along the lines, “we don’t believe the data in the database is correct or up-to-date”. The time which Raiser’s Edge has been used at an organisation is another factor in this - the data may well have been excellent when it was first implemented but over the years it has deteriorated. That happens, and often it is the poor database which is blamed. Data is the foundation of all good databases and if there are problems with the data then it doesn’t matter how good or bad the database software is.

• Set-up and configuration for your charity – during initial implementation and thereafter. The Raiser's Edge is a sophisticated but quite complex database to learn, even more so to use optimally. And how you use it, how it is configured, where you store data, how you use the “cornerstone” codes and so on can seriously affect how good the implementation is. Codes such as Constituent Codes, Fund and Appeal codes, Action Types (horribly abused in some systems I’ve seen) attributes and so on all need careful attention. And continual attention – if such tables grow uncontrollably they can become unwieldy and unusable. And where you store specific data items - attributes or ‘cons codes’, Appeals tab or Actions, etc – can fundamentally affect the usability.

•  Your Raiser’s Edge Database Manager. For a starter, you need one. Don’t try without. And a good RE database manager is worth their weight in gold: a good database manager not only understands the software, how to use it, what it can do and so on, but can also understand or learn your business, operations and needs and can apply all that information to the implementation so that it bring huge benefits to your charity. I don’t believe that Raiser’s Edge database managers need to be extraordinarily technical people (although a solid technical understanding is very useful) - far more important to me is that they can apply your fundraising requirements to your fundraising software. Give me a business expert with some database knowledge who can learn the system over a ‘pure’ RE database manager.

• Training, procedures, user guides. Again, it doesn’t matter how good or bad your software is, if your users aren’t trained then how can they be expected to use the database to its best potential? And ideally, good procedures and user guides to back-up the training are a key element to the success of the database. (Anyone actually have a data dictionary..?) And please keep them up-to-date…

• Hardware and IT infrastructure. Probably one of the most common complaints I hear about The Raiser's Edge, or any database is, “It’s so slow…” Now of course this could be how the database has been designed by the software supplier, but if one implementation runs fine and the next does not, even with similar record numbers, then that is less likely. Just as likely (more likely?) is that your server or PCs are not of the recommended specification, your network performance needs investigation/optimisation or the IT infrastructure for your remote offices is not sufficient for the database.

• Applicability to your organisation. This is one area where it is feasible that The Raiser's Edge may not be the right database for you. If you are a small organisation with few records or a huge organisation with many millions of records, then The Raiser's Edge may not always be the most applicable. Blackbaud, understandably, will show that RE can help small organisations and that even RE7 can manage millions of records (although their next generation Infinity platform will be better for that), but it is feasible that other solutions could be more applicable. This is of course one point which is completely organisation-specific. It can also be the case that over the years your requirements have changed so that The Raiser's Edge may not meet your current requirements whereas it did originally.

• Blackbaud-specific likes: The Raiser's Edge is generally good quality software, it has good querying tools, and is especially useful for non-technical users; and Blackbaud offer great longevity as a company and have produced many upgrades over the years and with exciting propositions for the future. Users like the software and the company for that. It has many charities using it so you get a good user community.

• Blackbaud-specific hates: Hmm, this really can be a favourite topic for some fundraisers and database managers! (And I’ve certainly had my own gripes over the years…)  As mentioned above, The Raiser's Edge is sophisticated but complex software (in fact, “The Raiser's Edge is so complex…” is probably the number one ‘complaint’ I hear about it) and it does need time and dedication. So if you don’t have people who can put in the time, or that is not your organisation’s requirement then it can be understandable why people don’t like it. RE7 can be quite prescriptive and in some ways it is less flexible than other companies’ offerings in terms of screen layouts, customised fields etc (unless one uses their VBA/API tools), and I personally believe that for the first time recently, RE7 is starting to show its age in that way compared to newer alternatives on the market. Equally, Blackbaud themselves are a large company and not everyone’s cup of tea, support has been up-and-down over the years (it has many clients and some users complain of feeling a small fish in a big pond) and users do relate to previous bad experiences. And it is not cheap. It certainly isn’t the most expensive solution on the market but there are very good, less costly alternatives for small organisations.

So if you are using The Raiser's Edge and you are finding it is not doing what you want it to do, then do consider the above points before you look for an alternative.