How To Tell If a Supplier's Lead Consultant is Right For You

 

I've written many times how I believe that one of the most important things for any database implementation is the database supplier itself. And within the supplier relationship, one of the most important relationships will be that between your supplier's 'lead consultant' and your staff. So you need to make sure that such a relationship is right for you. And one way to do that is to hold 'mock workshops' during the procurement process.

In almost all fundraising database and CRM system implementations you are going to have some sort of initial 'discovery phase'. This might be as simple as two or three days with the supplier where they take you through the options, discuss your needs and configure their system with you. Right through to several months of intense work with many workshops, software prototyping sessions, business analysis work and more.

Personally, I think that this is one of the most important parts of your implementation. Get it right and the subsequent system development will have every chance of going well; get it wrong and you're starting off down the wrong path from the word go. Not good.

So it therefore leads on naturally that whoever the supplier allocates to work with you as their 'lead consultant' has to be someone who you trust and who is right for you. That job title may go under various guises but essentially it is the person from the supplier who will lead you through the workshops, who will work with you in defining how the systems should be for you, will do a variant of business analysis of some sort, maybe even some project management, and will as a result work very closely with your staff.

So to find out if a supplier's lead consultant is good and is going to work well with your staff, one thing you can do is hold a 'mock workshop' during your database procurement. By this I mean that you should arrange a session whereby a supplier's lead consultant visits your office and leads a workshop with some of your staff in order that you can assess how that goes. This should be done in the same way that the supplier would do if this was a workshop during your actual implementation. The importance of this is not so much the subject of such a workshop, but more about the approach which the consultant takes, their connection with your staff, the confidence which they do (or don't) bring to your team, and so on. I have done this a few times and it has always been useful.

I wouldn't suggest doing it with all your potential suppliers and you need to wait until you are some way into the procurement process so that any short-listed suppliers can say who you would be working with if they did win your contract. As such, I would normally do this with, say, just the last two short-listed suppliers when we are getting close to making a decision. It is therefore one of the things we can bring into the final decision process.

And if you want to take this a step further, then don’t just ask for a mock workshop, but ask the supplier and lead consultant to then go back to their office for a few days/weeks and then return to show you what they would do with the knowledge they have gained from you. E.g. ask them to configure an aspect of their software for you based on the workshop subject, and/or ask them to show what documents they might create from such work. Don't take advantage of a supplier's time if you do do this - i.e. don't expect them to spend many man days customising a complicated part of your system - it should be just enough so that it shows they have put in some effort.

Yes this is more time and work for you and your staff, and of course for the supplier(s) too, but it is definitely time well spent. It's such a critical part of your project that anything you can do like this to try to improve the chance of success can only help.

Example Risk Register Template

In my most recent blog, I discuss the need for a risk register. But if you haven't managed one before, then where should you begin? Below, you can download the template which I start with on all my projects. Plus a few words of advice and ideas:

• This is just an example! Just a sample template. I hope it is useful but don't just use it blindly. If it's right for you then great; but if you want to adapt it, simplify it, expand it then you should of course do so.
• Likelihood and Impact ratings: I'm a bit of a fan of not simply saying High, Medium, Low without trying to clarify what each means. Otherwise it can be very subjective and different people can interpret such words differently. Hence why I use a key to try to clarify each level. But...
• ... What this does mean is that I don't allocate 1,2,3 etc and thus this particular template doesn't have an 'overall risk' column where you multiply the Likelihood by the Impact; e.g. if you had a High Likelihood (and score it 3) and a High Impact (also scored 3) then multiply them together which gives you a simple 'risk factor' of 3x3 = 9. Some people like this sort of approach.
• The Response column: is very Prince, so if you want to adapt that then go ahead.
• Colours: I have added different sets of columns in the spreadsheet in different colours just to show a bit of structure. But once you get going you might want to make all columns the same colour and use a colour traffic light system for the individual rows.

And of course: there are many other ways of listing, recording and managing risks, and the risk register (and any template) is thus just one aspect of this. My way isn't necessarily best. There are many good ways of managing risks. And it won't make you a risk management guru overnight!

I hope this helps. If you have any questions or ideas/suggestions then please do add them in the Comments below.

---

Click on the image below to download the template

There is no such thing as a risk-free project - but that doesn't mean you should worry!

 

A few words only: I was recently contacted by a charity who had identified a number of risks with their up-coming CRM project procurement. And as a result, were panicking somewhat over what to do and how they could proceed considering everything they now knew about the risks involved.

In such instances, what is important to remember is this: there is no such thing as a risk-free project - never. Not even if you had pretty much unlimited time, money and people. Even then there will always be some risks.

But don't worry! This is not a problem. Don't panic if you identify risks - just manage them.

Identify risks, document them, understand them, understand their triggers and outcomes. Find out when they could happen in the project. Determine how likely they are to happen and what the level of impact could be. Then make a plan to mitigate them, assign someone to manage that plan and monitor it. Create a risk register and review it.

And if you haven't implemented a risk register before, then look out for my next post and I will publish the standard template which I use on all my projects.

What now for Care, Integra, Donor Strategy...?

 

Advanced Computer Software, the latest owners of the Care/Integra/Donor Strategy/Charisma stable of CRM software systems for charities has been sold again, this time to US private equity firm Vista Equity Partners, in a deal that values the company at £725m. So what does this mean for the charities who use said products? After all, this is now the fourth time that Care, for example, has been sold in the last 9 or so years. Can charities continue to keep faith in the software?

A little bit of history repeating

To some charities, it must seem like deja-vous. For many years, Care Business Solutions was a ‘family-owned’ company and many large charities such as Marie Curie, WWF, Amnesty, PDSA and more have bought Care, and it was and remains a sturdy system. But in the last 9 years or so, Care has been sold first to the CS Group (mid 2000’s), then IRIS (in 2007), then ACS (early 2013) and now Vista. At the same time, Charisma was sold to Systems Group who then got sold to CSG and then, well, see Care. And sadly it hasn’t been plain sailing for all clients. If you talk to charities and consultants then certainly the time under IRIS was not perceived as a happy time, and that was reflected partly in new sales.

And on each occasion, unsurprisingly, clients have been promised “development plans”, “new investment” and “stability”. I don’t know how many think they have received that.

So does this matter?
I’m an independent consultant who really tries to present both sides of any story. And so I really want to provide a balanced analysis to show the pros and cons of such changes – but on this occasion I am struggling. I can certainly say that the key products listed above are still robust and operationally sound - which is something we should never ignore - and they have to a degree been developed (witness ACS’s NG development) and some of the staff from the various incarnations have stayed on. And of course there is nothing unique in such takeovers - it happens throughout the commercial sector and other NFP CRM systems have of course been bought and sold and continued or discontinued.

But at the moment I am wondering if such upsides are outweighed by the issues and possibilities which occur with such change: first there is continuity of investment (or not); then the continuity or otherwise of strategy/approach/technology for the clients and their ability to plan; indeed, consistency all round. And it is surely unsettling for the company’s staff (and although some staff have stayed, I understand that at least one of the buy-outs mentioned above caused considerable staff turnover); and also as mentioned above, the time under IRIS did not give Care/Integra users the best experience and certainly didn’t provide many significant new fundraising database implementations.

And now…?
So I guess I should start with the hackneyed but fair phrase: “time will tell”. That said… if you were currently looking for a new CRM system for your charity then where would you look? ACS already had competitors in at least Blackbaud, Salesforce and Microsoft Dynamics for their top-end fundraising solution (and more for some procurements), and thankQ for their mid to high-end NFP prospects; and their membership offerings had/have very strong competition from several Microsoft Dynamics ‘templated’ options as well as other vertical sector products.

So if a charity was to ask me what I thought was the future for Care et al then I would want to wait until we hear more from and about Vista. Basically, will it be different this time? Or will the 'acquisition tree' above continue to grow?

Integration Costs: Where to Start - and Where to Finish…?!

 

Integration is one of those words which can mean so many different things to different people. So for the purposes of this post, I don’t mean integration with third-party software such as Office or PAF software, but rather the need for data exchange or synchronisation between your new system and other data sources/databases. And as such, for any significant new database you will almost certainly have some integration.

As such, the sort of examples which you may therefore want to consider when integrating your database with other data sources include: receiving online donations, event registrations or any other data from your own website; data from JustGiving, VMG and other peer-to-peer fundraising websites; other supporter engagement websites (e.g. Engaging Networks); data importing/exchange with fulfilment houses; and data exporting to finance systems.

Sadly, the costs for such integrations can start to add up and they ain't necessarily cheap. So, a few key things to consider are:

• Have you identified all your external data sources? Do so, in order that you can definitely decide on the best approach(es) for integration, so you can prioritise and of course to make sure you don't miss any critical data feeds.
• When implementing a new CRM system, just because something was integrated in your existing (legacy) database, doesn't mean it will be easy to integrate it in your new CRM, at least not necessarily on day one.
• Do you really need real-time integration? People often say they do, but how critical is it? The reason you need to ask is because real-time integration usually means higher costs and more complex integration
• As such, 'batch process' integration is still more popular than real-time for most charities, and even for many corporates.
• Custom-coded integrations are barriers to change: especially for small organisations. This is because they are more complex and more specialist to create and far more time-consuming and expensive to change later. Keep it simple for future simplicity.
• You don’t need to make exclusive choices on integration - you could do one integration in one way (e.g. integrating your website and your database using web services) and several other integrations another way (e.g. batch imports from csv files).
• Watch out for "integration transaction" costs when implementing APIs. If you do go down the route of using API services for integration then some systems (e.g. some cloud CRM systems) will charge extra if you go over x transactions per day. And although the starting point of charging can often seem like it only kicks-in with high volumes, a single "integration transaction" through an API is not necessarily, say, a single financial transaction (donation) from a website; i.e. using an API to add a single donation to your database might involve multiple API transactions.

So: what makes us think it will be different this time?

 

It's a sad fact that so many fundraising/CRM database implementations fail or are not nearly as successful as we hoped. And although there are various potential reasons for this which are central to many of my blog posts, we can also look at this problem in another way - if you have experienced a failed project at your organisation in the past, then ask yourself this: If we are about to launch a brand new CRM procurement and implementation project, what makes us think it will be different this time?

If this strikes a chord with you and you want to ask this question internally at your organisation, then here are some questions you could consider and try to address. Hopefully, they will (at least start to) give you the ability to decide whether or not you have learned from previous projects and tell you a lot about yourselves before you embark on another big project.

• What were the reasons for failure on the last project? (Did we even hold a Lessons Learned meeting?)
• Did we even define success criteria? Were they measurable, achievable, realistic?
• Do we have a proper business case? Has it been ratified by more than just a couple of people?
• Are we asking the same people to run and be involved with the new project? If so, why do we feel they can now do it? Do they have that much better experience now? Do they know all the pit-falls they could encounter this time? Have we sent them on any sort of training or learning programme since?
• Have we got new people involved? Are they any better?! Do we need more people?
• Are our senior managers fully engaged?
• Do we understand what our risk is? Do we know how to mitigate or accept risk?
• How do we really know we have got an appropriate budget this time around?
• How do we really know our planned timescale is possible or realistic? Could it even be too slack?
• Do we have a project manager? What sort of experience do they have?
• Do we have project governance? Do we understand project governance?
• Even if we do feel we have learned lessons, how will we monitor the next project to make sure it stays a success?
• Was our actual data an issue? Do we have new faith in that now?
• How can we be sure that the next salesperson we meet doesn't spin us the same lines as last time?

As I said above, in some ways many of my blog posts encompass the above in specific areas or in more detail. So please do search for anything particular in my blog archive which might come out of your considerations. (And hopefully the links within the above list are a good starting point for other useful posts).

Maybe I can use a famous Albert Einstein quote to sum-up: "The thinking it took to get us into this mess is not the same thinking that is going to get us out of it."

Can End-Users Really Use Data Analysis Tools Without Data Experts?

There are some incredibly good end-user oriented data analysis software systems these days. Really user-friendly, lots of great graphical drag-and-drop functionality and one can get all sorts of analysis from them. Even the new CRM systems provide decent user-oriented tools which can be learned by non-technical staff in a comparatively short amount of time.

But herein lies the rub: if we make it so easy for end-users to be able to use what is actually quite sophisticated software, then how do we know they are using it correctly? Or more to the point: how do we know they are getting the correct data, getting the correct data which they really want, and interpreting the correct data correctly?

Let's take the simplest of examples: a user wants to know how many supporters they can mail for their next event. This means knowing how the database and data defines such supporters, knowing how to exclude deceased/gone-aways etc, knowing other opt-in and opt-out codes, knowing the opt-in and opt-out policies, knowing the meaning of the values within a specific field, knowing if other groups of users might want to approach the same supporters at the same time. And knowing exactly where and how all this is held in the database.

Maybe it isn't that easy after all… Add on any further level of complexity such as last raffle gift (not just any gift), average gift over the last 3 years, if they came or were invited to the same event last year, and you're starting to tax even the data experts.

Which is why so many charities have centralised, specialist data teams who do such work. Or at the very least, highly trained users in each fundraising team. With this approach, we can be sure that the specialists know not only the data and all the above conundrums but they also know what additional questions to ask the fundraiser who wants to know such answers.

All of which pains me a great deal to have to write. I want end-users to be able to run such queries themselves, I want them to be able to be empowered to ask 'what-if' type questions so they can see data patterns, I want them to be more self-sufficient so that it will help them and take some of the strain off the database team.

But to get such analysis software to a point where this is possible, to ensure the data is so easy to understand that anyone and everyone can do, to ensure that internal policies are fully understood - all that is not necessarily easy.

Which doesn't mean we shouldn't try to do it and it doesn't mean it can't be done. We just have to ensure that appropriate software and data and policy training is given to those who need to know - and probably to limit the sort of reasons for why they are doing it in the first place. i.e. As long as the users are doing such queries just to get rough counts, to get some idea of data, to be able to do a first data sweep of a data mining exercise, then I think that should be possible. But sadly I don't think even the best software in the world yet means that a end-user can do their own segmentation and create their own mailing files for their next big event. We still need the data specialists for that.

The new world of cloud storage - do you really need ALL your old data?!

Traditionally, when moving from one fundraising database to a new one, charities tend to migrate all their old data across - or very nearly all. Sometimes, small sub-sets of old or truly unneeded data may be left behind, but in the main, every single donation, communication, appeal record etc and every entity and every field is transferred as is to the new database.

Why? Well, understandably, fundraisers and marketing staff are worried about losing granularity of historic data, of not being able to do true and useful RFV calculations or similar analysis on summary fields, of not being able to look back at why someone responded to appeal X or came to event Y. And the thought of either not keeping their data in the most granular state possible, or even not transferring it at all, has been a complete anathema!

But recently, this is something which is being challenged. This is partly due to cloud CRM systems charging for extra storage, partly due to some performance concerns for complex processes on very large systems and partly to mitigate some of the risks and complications of data migration. And partly it is just good business practise to challenge such assumptions.

But Why?!
But just as pertinent a question for me is: Why - Why do you need ALL your old data? Really - why?! I mean, are you really going to look back at someone's communication history from ten years ago and want to see that a donor was sent a second letter because a particular acknowledgement letter didn't reach them first time? Do you really need to know that someone was invited to an event twelve years ago but didn't respond? I'm not sure if you do…

And although I completely recognise the need to keep a granular donation history for at least a set number of recent years (e.g. at least four years for gift aid claims), at what point are your fundraisers not going to use such data for segmentation and marketing analysis? Five years? Six maybe? In which case, do you really have to be able to see each individual donation for older periods as a separate financial transaction on your new system? Or actually, could a summary be acceptable? e.g. a summary by year/campaign/gift type/whatever is appropriate for you.

Of course, there are some data items you would definitely need to keep, such as first donation information, maybe upgrade details etc, but do you have to have more than that for donations over a certain age?

And if you do, if you have to or if your organisation is too paranoid not to keep such data, then maybe you can store it elsewhere for when (if!) it is needed. For example, a separate data warehouse, maybe a simple SQL Server database, even a separate marketing software system.

And what about any old data which you still have on your system but which almost no-one in your organisation trusts and so doesn't use anyway? Does that really need to be transferred? Really?! And data accuracy in general - just how good is it over a certain period anyway?

Or, Should we be asking, Why Not?
Now. One could of course ask why we shouldn't migrate all data and that's a fair question. Storage does cost but is it so much more? And contemporary systems are so much more efficient now than older systems, why shouldn't we have millions of records in our new database?

Well, maybe because more data does add extra data management, does add complexity when doing segmentation and reports/analysis, can slow down a system when running such processes, can make screens slower to load when they have lots of historic information, can make data migrations more complex etc etc.

I think it is an interesting challenge - one I encourage you to consider!

Why online giving platforms and your own fundraising database are not best friends

 

The IoF/CFG recently published a new report, "A practical guide to selecting and using online giving platforms" and I was pleased to see that the data collected from such platforms and, to a degree, the integration with your fundraising/CRM databases was acknowledged as a factor. However, I think such integration is sometimes promoted as being easier than it really is; and sadly, integrating or importing said data into your own fundraising database is often much more awkward, time consuming and costly than charities realise.

There are therefore a number of things I think you should consider if you do want to get the data from your online giving platform into your own fundraising system:

First, the data basics
Just because a platform provides a file of donors/donation data in an Excel/csv format doesn’t mean you can import it quickly into your fundraising database; e.g.:

• You need to consider duplicates - how will you identify if an online donor is already on your fundraising database? And even if you can, can you easily update data correctly? i.e. if you do find a duplicate then is there any data which you should update on your own database? Or should not overwrite?
• Some fields in your downloaded file may need to be split (or even concatenated); e.g. name, address fields.
• Some fields may exist in your downloaded file but not in a way which can directly be added to your database (e.g. Gift Aid declaration data/flags, opt-in/out flags).
• Other fields not in the downloaded file may need to be added to a file before you can update a record on your database (e.g. source, fund/campaign codes) etc.
• Gift Aid flags need to be carefully updated so there is no double-claiming in the future.
• Then you have regular giving and how to distinguish/code/incorporate these, and match income when it comes in...
• And you have the issue of Soft Credits and how to apply those to who…

There are also sponsored events to consider, which are of course where so much data comes from the online giving platforms. It's all very well including sponsors who have ‘opted in’ to receive more information from you, but if it takes more time/effort to import then what are the expected benefits? Are those people really interested in your organisation or just the person they sponsored? What is the real likelihood of getting a further donation from them?

And the reason all this is important is because if you do need to manipulate and change the files you are downloading from the online giving platforms, then someone in your charity (i.e. usually someone in your database team... if you have one...) has to do that. Some charities are better than others at doing that and some do automate such processes in Access/Excel macros etc, but I know many who still do at least some manual work, and some who do considerably more than "just a bit".

Some (potentially) better options
There are of course more automated ways of importing all this data. e.g. JustGiving provides an API which means you could import such data much more efficiently. And some of the fundraising packages and some of the fundraising templates now provided for Salesforce/Dynamics even have 'out of the box' functionality written for you to do this. Which is definitely a good start. But remember that even those pre-defined processes might not always do exactly as you want.

And if any online giving platform says “oh, we have an API so you can integrate us with your database…” then, well, just be aware - it ain’t necessarily as easy as it sounds! If you have internal programmers and techies then great, that’s an option. If not, it will cost you money.

The benefit and curse of multiple online giving platforms
Of course, the kicker is that for all the above points, you need to consider all of them separately for each online giving platform because each platform's data and file format will be different… That's why database teams groan (inwardly) when they hear about the "next, great online giving platform", because they know where the buck will stop in terms of getting that data into your own fundraising database.

And talking of bucks, this final step of getting the data into your own system is sometimes not considered when looking at the total cost of different systems. Sadly, it does seem to be assumed by some charities that if a database team can do one such solution then they can do another without any additional cost/work. And as I am saying, this is not the case.

Don't get me wrong: I love the fact these platforms exist and it has revolutionised fundraising. But to maximise future fundraising benefits, you need to get data from those platforms into your fundraising database and use that for future marketing. And that is not always as easy as it sounds.

Raiser's Edge NXT: My Initial Thoughts (Part 2)

Last week, Blackbaud announced details of Raiser's Edge NXT. In the first part of this blog, I gave the facts of what I currently understand NXT to be. In this second part, I will say a bit more about what I personally think of the system and the implications for current RE7 users/potential new NXT users. As such, I should add a great big caveat at the start which is that this is my own personal opinion and so you can blame me for anything I am ultimately wrong about (or, hopefully, right!), but I hope that this post is at least a fair and open narrative.

What's Good about NXT?
The good news is there is lots to look forward to about NXT. It's interface and UX is undeniably very slick and far more user-friendly than RE7. There are definitely better features such as the approach to dashboarding, the work centre, the summaries users can easily see and the far more flexible way of displaying information. It looks good and that will certainly help user adoption. (Of course, that is only one aspect of any software, but it's a great start).

The different role-based views are promising and although that might add some extra support to database administrators to maintain them, I would still vote for and want that flexibility.

It supports REST API technology which means that using its API should be a far better experience compared to RE7's API which many people didn't like. What this means in practise is that your technical staff, or Blackbaud or third-parties should be able to integrate NXT more easily with other systems and get data in and out of the database better using such tools.

The conversion approach (which I detailed in part 1 of this blog) is clever in itself, although I have reservations too for the initial implementers (c.f. below).

And for those of you who want a cloud-based fundraising database it could be a great option.

Of course, the above sub-heading means I need another which says there might be stuff I think is not so good…
So what are my concerns/questions about NXT?

• In the short-term (although that actual timescale is currently unknown), I am not sure how the approach to using RE7 and NXT at the same time will be received. You can look at it on the positive side and say that it is of course great that some users will get earlier access to NXT, or even that some users will have an option of which system to use, but I think there are issues that may need to be resolved.
  
  I would think it could be harder to explain to users who should be using which version to see what; and administrators will need to support both systems. And as more NXT functionality comes on board, so testing, training and internal documentation will need to be kept up-to-date on those aspects. There's some potential 'hidden costs' there in terms of internal staff time/effort. And although some existing RE7 clients might accept all that, it will be interesting to see how that is seen by potential new customers. (NB I realise that the software interface is simply one aspect of any procurement decision, but it's quite a significant one in this case).

• I'll be interested to see how Attributes are ultimately managed in NXT. As I understand it, at the moment Attributes will simply be migrated from RE7 'as is', and that is probably a good thing for ease of migration and for initial adoption.
  
  But if Blackbaud are promoting NXT as a great UX and with their role-based views, then if users can only still see all Attributes all in one list and then have to work out from there which are relevant for them, then I don't personally believe that is taking a step forward in that aspect of the UI. I know many organisations who have dozens (many dozens) of Attribute categories. That said, I think users may be able to filter the Attributes list in some ways so that is going to help.

• When RE was originally released, attributes were a very clever way to enable non-technical users to be able to add their own 'fields'. And they are of course still very easy to add. But today's CRM systems (Blackbaud's competitors) offer charities the ability to add 'standard' fields very easily, simply through using a GUI and still without the need for any specialist technical knowledge.
  
  Again, I know that this is a very specific point but I personally believe it is an ever-increasing example of user-friendliness with power which NXT might need to catch-up with. I also acknowledge that at some point, if users want this capability a lot then they should maybe consider Blackbaud CRM, but that doesn't really address the NXT needs.

A few things we don't know yet but will start to do so
We don't yet have a timescale for a full implementation of NXT so that it replaces all of RE7. The only thing we know is that it won't be a matter of just a few months. So the 'hybrid' approach will be here for a while.

And as the pricing won't be based on user numbers then I assume it will either be based on record numbers and/or online storage requirements. How this works out will depend on Blackbaud's final cost model.

One of the things we will need to know is how Blackbaud will allow and manage client-created and third party API developments. Current RE7 hosting has limitations on third-party APIs so will that be the same on NXT? I believe that existing add-on functionality built on RE7 using RE7's API functionality will also be replicable on NXT, but it isn't completely clear to me how that will happen. Will it only be for API apps built by Blackbaud on RE7 or by third-parties/clients too? This is especially pertinent given that Blackbaud are launching a Partner Network in November this year.

There was talk on Twitter during the Blackbaud conference announcement that there could be a private cloud option. In which case, that would seem to offer more functionality for control of performance management and flexible use of the future API.

So how would I summarise all this?
Although I know RE7 is still selling fine and fundamentally it provides solid operational functionality for fundraising, it is difficult to argue against the view that it looks a bit long in the tooth, it is based on older technology and it is more difficult to integrate with. And all that whilst (some of) Blackbaud's competitors have surged ahead in terms of technology and an open approach to integration, and are already challenging on fundraising functionality.

NXT will address this. That's good news for the sector in terms of software options. Especially for small to mid-size charities already using or considering Raiser's Edge, which is where I suspect NXT will do well.

But it still won't be available until the middle of 2015 and even then it won't be replacing 100% of RE7 functionality. The time Blackbaud take to develop NXT further could have a significant impact on its adoption. And as I say above, I remain to be convinced as to how the 'hybrid' approach to using RE7 and NXT will be received by some users.

I also don't know if the cloud-only approach will alienate some organisations? It shouldn't do in terms of cloud security although there are of course some people who are still wary of cloud systems - but the management of client/third-party APIs could be important here too.

But as a one sentence summary? I think NXT will put Blackbaud back in the game (if they were ever out of it…)

Raiser's Edge NXT: My Initial Thoughts (Part 1)

 

Last week, Blackbaud announced their roadmap and upgrade path for The Raiser's Edge v7: Raiser's Edge NXT. My post here summarises what this means to existing RE7 users and potential NXT users. I've split it into two parts: first the facts and second what I think the implications are for RE users ¹.

First, just the facts ma'am
So what do we know about NXT:

• Raiser's Edge NXT (oh, and that's pronounced En Ex Tee - not next or n'xt- although I'm not sure how long that will last…) is a cloud only solution. No more on-premise software.
• All clients will have unlimited users and instead the cost will be subscription based pricing (exact pricing TBC).
• It will be device independent and run on desktops, tablets and mobile devices, the interface being a responsive design.
• The whole user experience (UX) is very different from RE7 and is "tile-based" rather than tab-based, which can be setup differently for different users (c.f. Roles below) and the tiles can even be moved around easily. (You can see several example screenshots on Blackbaud's website, such as https://www.blackbaud.com/image/renxt-desktop-1.jpg)
• The fundamental UX is designed so that it is more focused on different user Roles; e.g. a view for a fundraising manager, one for prospect researchers, another for alumni relationship officers etc. This means that each such role will have a different view of data and records oriented to how those people work.
• It will support the REST API architecture. And, as it says on Blackbaud's website: "Raiser’s Edge NXT will ultimately have an Open API".
• There is a new approach to list building which is oriented towards users who don't need to know something as sophisticated as the current RE:Query tool (and is more akin to filters found in other contemporary/cloud CRM systems).
• And there are some other nice new features and functions too such as better dashboards and summaries, a work centre, a constituent "timeline" which shows interactions/mailings etc for a constituent in a 'graphical' view - and I expect many more.
• Upgrades/enhancements will be automatically rolled out when they become available, a la any similar Cloud solution. (i.e. no more going round all your PCs with a CD!)

And the planned release date is middle 2015. But: in the first instance, NXT will not have 100% of RE7 functionality. Instead, more functionality will be added over time. That will mean the first organisations using NXT will also need to carry on using RE7 for some of their staff/requirements. (c.f. Data Conversion below). In practise, the initial launch will provide the NXT interface for users more involved with one-to-one type fundraising (major donors, trusts, prospect researchers etc) but much of the central operational functionality of Raiser's Edge will remain in RE7 (e.g. direct debit claims, exports, database admin).

And for existing RE7 users there will be no data conversion process…

So how will current RE7 users 'convert' to NXT?
Although there is no 'formal' data conversion process, it is perhaps better thought of as an "invisible" conversion (or 'behind the scenes'). It will work like this:

• First, if you are a RE7 user who wants to upgrade to NXT then Blackbaud will move you to their hosting platform (if you're not already on it).
• That platform will then provide you with full access to RE7 (as per their current hosting option) but also present NXT access. But the data will synch between the two versions so that all users are of course accessing the same data. All this will be done automatically by Blackbaud's systems.
• Thus we can see that data from RE7 will start to be migrated to NXT and as Blackbaud bring on more functionality to NXT so more data will move across to that.

You can read my thoughts on the implications of that in the second part of this post.

And don't forget Blackbaud CRM and eTapestry
If you are an existing RE7 user then you should also remember that NXT will be just one option for an upgrade path. For larger organisations, Blackbaud CRM could be more appropriate, or for smaller organisations you could even consider eTapestry. Talk to your Blackbaud account manager for more information (as the PR might say…!)

So what does all this really mean to Raiser's Edge v7 users? How good is RE NXT?
I will address that in my next blog, later this week.

---

Notes
1: This information has been gathered from Blackbaud's own website and from Blackbaud's announcement of NXT at their US conference last week.

The importance of the client/supplier relationship

 

This is a slightly corny sounding subject at first sight, but it really is true and it really is important! The following are some of the things I have learned over the years which you might like to consider when buying and then implementing a fundraising, membership or CRM database (or anything else come to that!):

• The first thing which helps in this area is that hopefully you will consider supplier empathy and approach even during procurement. Especially the lead/key staff you will be working with. If you select a company where their staff do appear awkward/unhelpful/blunt or just don't care about what you are doing, then that isn't going to help... You might do this if everything else about the company and software was so fantastic that you had to do so, but personally I wouldn't advise it. (This may be an obvious thing for me to say but in the NFP sector this can truly make a difference, compared to a hard-nosed commercial organisation)
• The supplier should be on your project board/steering committee during implementation. This will really help the relationship and project. And if you also need to hold private board meetings without the supplier then that's fine, just make sure they are part of the key meetings.
• Set ground rules for both parties in your kick-off meeting: start as you mean to go on. It's the best time to do this when you are both happy and enthusiastic!
• Invite your supplier's key staff to one of your organisation's away-days, SMT meeting, fundraising planning workshop etc at the start of your implementation. It will give them a far better insight into what your charity does, what is important to you, what your staff are like and so on. (NB For suppliers who work with commercial clients too, you might well find their staff find it a refreshing thing to be working for a good cause - and the more engaged they are, the more likely they will pull out the stops to help you when push comes to shove).
• Don't squeeze suppliers on costs til they bleed - it will backfire. They almost certainly will be a for-profit company so understand you do need to treat them as such.
• Your contract should include a SLA (Service Level Agreement).
• Ensure you have an Escalation Policy which covers what you will do and who will do it - for both parties - if anything does need escalating.
• Build a more personal relationship with the supplier's key staff so that if you do have a problem or an awkward thing to discuss then it should be easier. Ditto if they need to come to you about such issues. Visit their office, meet their other staff, meet their CEO (or as high as you can go - you may not meet Marc Benioff or Satya Nadelle themselves!)
• And when things go wrong, discuss them as openly and as honestly as possible. Don't shout! (I know this is basic advice but I have seen situations when it has not been followed...)

Beware fake implementation timescales

 

This is a brief message: if you have been asked to plan a new CRM or fundraising database implementation, and you have been told to create a timescale for the project, then beware of the 'fake timescales' syndrome.

For example, if someone in your organisation (usually a senior manager…) says it must be done by date x, if there is no solid business reason for that date then don't just accept it. If you have over-run your procurement by a couple of months, then don't simply reduce the implementation time by 2 months - why has it suddenly become quicker to do just because you're starting later?! Or if your timeline is based on the fact that someone once did a project somewhere else in that timescale...

Of course, if you have an absolute deadline for a good reason then that needs to be accounted for, although even those can sometimes not be definite. e.g. if you are moving office, then is there no way you can continue to access your old database in your new office - or is that just an excuse to get a deadline? If your current software supplier is stopping the support of your current database on date x, then maybe you can accept the risk of still using it for just a short-time after that rather than rush your new implementation?

What you should do is work with your supplier and your project team, your key staff and your organisation's whole calendar, and work out how many months the implementation should take regardless of when you are starting. (Then review it again and see if even that is realistic…) Then you can allow for any periods which might mean it could take longer (e.g. Christmas/New Year, your big annual event, August holidays) and extend if it necessary. And if that really, really is unacceptable to your project board then you will need to explain you will have to de-scope something and/or increase resources.

But don't accept fake timescales - they don't do anything except increase the risk of failure.

During a procurement process, make sure you meet staff you will be working with if you select that supplier

 

Many people probably know the importance of this tip, but if not then you should do: when you are running a procurement process and you are meeting potential suppliers for your new CRM or fundraising system, make sure you meet the actual people from each supplier who will be working on your project. You need to be sure they are appropriate for your organisation and your project and you need to be sure that a supplier will not roll out their 'A team' during a sales presentation and then bring an entirely new team if they win the contract.

Getting the right people from the right supplier is a critical part of any procurement and subsequent implementation. You can meet the most charming and knowledgeable salesperson and pre-sales staff and then find that the implementation team know next to nothing and have no empathy with you. (Conversely, even if you don't like a salesperson, if their project team are good people then you might well overlook the dodgy salesman!)

So ask the supplier about who you could be working with, their skills and backgrounds, what other charity/fundraising/CRM projects have they worked on, why are they good, how are they trained, what is their knowledge of fundraising (or membership or service delivery…) Get their cv's. And meet them.

My one caveat to all this is that you need to do all this at the right moment during your procurement process. There is less point in doing it when you are still half a year ahead of a project kick-off - who knows what will happen between now and then; and it may be less fair to ask a company who is still on a short-list of six or seven possible suppliers for your project to name the definite people you will be working with. A supplier can't necessarily make such commitments at that time. That said, even in those scenarios you can (should) ask to meet the staff you might be working with and even that will give you an idea of the sort of person which the supplier employs - and then once you are down to your final few companies then you can start to be more firm with the suppliers and ask them for actual names and meet them.

When buying CRM systems, do consider multiple business partners for each platform

 

One of the great benefits of the generic CRM systems (Salesforce, Dynamics, CiviCRM etc) is that there are many business partners for all of them (aka resellers) who could help you implement such systems. But if you are considering such solutions during your procurement and you just have one supplier per platform pitch for your project (e.g. just one Salesforce reseller, one Dynamics reseller etc) then you will be missing out on all sort of possibilities.

For a start, each partner/company of course has their own approach to implementing such software for charities. And if you find that their approach, ethos or people are just not right for your organisation then you could be automatically eliminating 'their' platform but based more on the company than the software/solution. And that might be reducing your options in the wrong way. (Of course, it is quite understandable that you don't select a company because they aren't right for you, but I would suggest you should give yourself scope to understand alternatives apart from said company for said platform).

Then there is their knowledge, skills, background, experience and so on. And their beliefs and ideas as to how best to do such implementations. If you don't look at multiple suppliers for each CRM system then you will only see that system through the eyes of one company, and I think that presents quite a risk for you in not necessarily seeing the best of it - or conversely, understanding its weaknesses.

What if you have a business critical requirement such as processing direct debits or managing online event applications and you hear from just the one supplier that this can't be done on 'their' platform - then should that mean immediately that you can't use that system at all? Or as bad, what if you only select one supplier and they tell you they can easily do that function and then two-thirds down the line it turns out that they can't, then have you wasted an opportunity in understanding that platform better?

Even if you only review two such suppliers for each platform then you will learn so much more from each one, and thereafter even if there is one who you definitely don't want then it is still quite feasible you will learn something from them which you can use with the other business partner. (And even if you don't, then even that will tell you something as to how good and how much more appropriate your chosen partner is!) And remember, as per my recent blog post, you can also consider Pre-Qualifying meetings before short-listing to a final one or two suppliers per system, thus enabling the potential for even more comparisons.

Try Pre-Tender Qualifying Meetings with Suppliers

 

One long standing question with every CRM procurement process is, Who should we invite to tender for our project? You might well know some companies who you want to invite, but there may well be others you have heard about, researched or you are interested enough in them that you want to know more - but (probably) the last thing you want to do is to invite ten or twelve different suppliers to do long software presentations and answer even a medium length ITT document. Apart from anything, if you tell a supplier that they are one of twelve you are inviting to tender, then they aren't going to be nearly as driven to commit time and effort to your project as opposed to when they are one of four or five.

One option is therefore to hold 'pre-tender qualifying' meetings. (It's a bit similar to OJEU PQQs). For this, you will still need to meet at least those suppliers who you are uncertain about (and maybe even all possible suppliers - c.f. below) but only for a shorter time and with a slightly different brief. Bearing in mind the importance of the supplier themselves, their knowledge, skills, client-base, project approach and so on, you will gain an awful lot in these meetings just by discussing these sort of things with the suppliers even for just a couple of hours each. That's enough to give you a better understanding of them and for them to feel they are being listened to, but they don't have to spend many hours preparing for a detailed presentation or answering a long ITT - and you don't have to sit/wade through such presentations/documents.

And for anyone who doesn't think that this is long enough to assess a supplier's capabilities - well, I really can say that those who don't cut the mustard are fairly evident. In fact, I'm quite surprised at how poor (sadly) some prospective suppliers can be. You'll know them when you see them. And it's not just me who has found that out - the clients I work with are just as savvy at picking up on the poorer candidates. Okay, every now and then we might see a company who initially impress us and then we later find out they aren't quite all they were quite cracked up to be, but that's comparatively rare and that is part of the procurement process.

I do sometimes also ask suppliers to give me a brief demo of their software in such meetings, but I do so mostly where I already have some idea of that software - e.g. especially with the generic CRM systems. It isn't fair to a supplier to ask them to give you a thorough demo for the first time in just 30-45 minutes, it's almost not worth it. But if you know the basics of, say, Salesforce or Dynamics, and you instead want to see how a supplier has configured it for another charity or type of fundraising, then that can help.

I also always ask suppliers to bring at least one of their project team who our charity could be working with to these meetings. So it's not just the salesperson you are meeting, but, also say, a project manager, implementation consultant, technical architect, support manager etc. The suppliers who value your business will do so. Those who do only bring a salesperson will tell you something about the company too.

After all these meetings, you can then short-list to, say, between three and five companies (or whatever number you are comfortable with), in order to get right down to detail.

I find this process especially useful these days with the sheer number of possible "CRM" suppliers (i.e. the Salesforce, Dynamics, CiviCRM partners etc) where, even though they are using the same platform, there can still be distinct differences in a supplier's approach, knowledge or how they use the software. But it is equally useful with the fundraising package vendors too.

In terms of fairness, if I am holding such meetings, I would do this not just with those suppliers who I may or may not ultimately short-list, but even with those who I am pretty sure I will short-list anyway. That means you can judge everyone equally, give everyone the same possibility to impress (or otherwise) and you are bound to learn something at this stage about everyone, whoever they are.

Do you really need real-time integration?

 

For some reason, when users request integration it often seems to have to be "real-time" integration. This may just be because 'real-time' is a bit of a buzzword, or because it is used without really being fully understood, or it may be because someone (a salesperson?!) once told them they simply had to have this... But if you quiz them more deeply then I would suspect that very few applications which charities run have to truly be "real time".

And the reason that is important is because real-time = really more complex and expensive.

First off, it is worth defining real-time within this context: real-time for a charity could be when, say, someone makes a donation on your website and then that donation is transferred 'immediately' into your fundraising/CRM system. But even here, 'immediately' could be several seconds which for us as a charity pretty much is real-time - as opposed to, say, a share-price system or a car's ABS system which has to react within nanoseconds. The important thing to note is what real-time does not do which is that it does not simply pass the data to a 'queue' of similar transactions which is then transferred into your CRM system sometime later using a 'batch process' of some sort.

So, if we consider this definition, then when do we as charities really need real-time integration between another system and our fundraising/CRM system? The above example of online donations or event registrations is a good case in point: if a donor was to phone your supporter care team within moments of making an online donation then maybe real-time (or near real-time) would be very important. But although I know that scenario does happen, it's rare. And there could quite feasibly be a simpler, cheaper workaround for that such as your supporter care team having access to, say, a web portal to your online donation/event management system. I'm not saying that is definitely the best approach, but it should be considered if a real-time option is prohibitively expensive or complex. If it's not - and actually, these days, such real-time integration between CMS and CRM is increasingly more straight forward - then go ahead, knock yourself out with it.

But I would really question the need for real-time for many other applications. For example: if you are only getting a handful of online transactions a day and no-one needs to know about (or is available to know about) them instantly anyway; if you have a fulfilment house processing your campaign cheques; if you are receiving files from CAF; and so on. In those instances, it is probably perfectly acceptable to have batch process integration. And batch integration doesn't have to be daily, which is how it is often thought of. If it is automated then it could be every n hours etc. But it will (almost certainly) be a lot easier and cheaper to implement and maintain.

The CRM Alternatives to Salesforce and Dynamics for Charities

 

Salesforce and Microsoft CRM Dynamics are both great solutions but when considering 'generic' CRM systems, it is easy to think that they are the only "CRM systems" available to UK charities, which of course is not the case: there are dozens of similar(ish) systems on the market - and there are of course fundraising database packages. That said, there are some CRM systems which are either more oriented towards the NFP sector or where a supplier has specifically created modules for charities, or where one or more business partners have taken the sector seriously enough to have made an impact with what they can provide, and it is those systems which I thought it would be useful to list here for awareness:

• CiviCRM: CiviCRM has been designed specifically for the NFP market with appropriate functionality and ethos, and is almost certainly the NFP sector's leading open source CRM system, offering collaboration and joint development. And because it is not oriented at just one "type" of solution for charities (i.e. not just service delivery, not just case management, not just fundraising, volunteer management etc) it has a degree of flexibility similar to that which the CRM solutions also offer, if maybe not quite so in-depth. It has a great ethos for charities, and an ever-growing and broadening community using it and supporting other users. And by its very nature it tends to attract users and developers who believe in not just the software but the whole open source approach. But the fact it is not driven by a commercial organisation means that when statutory or regulatory requirements change, then a user and/or the community needs to get the software updated to manage that.
• Workbooks.com: Workbooks has gained several UK clients in the membership sector and are offering their solution to charities too. It is a web-based (SAAS) solution designed for small and mid-size businesses, so in terms of solution size their NFP offering should fit many charities. Unlike Salesforce/Dynamics, they (primarily) sell direct to end-user organisations.
• SugarCRM: Sugar has an open-source and a paid-for commercial offering and has had some adoption with charities and the public sector, partly due to its cost structure but partly because it is a decent system with an especially good interface. It can be hosted or run on-premise and is sold and implemented through a partner network. It has perhaps not made inroads into the sector quite as much as the other systems.
• NetSuite: A large, CRM vendor in the US, they have created NetSuite.org which is the corporate citizenship arm of NetSuite. They offer product donations, pro bono programs and social solutions to charities and NFPs. Not yet as well adopted in the UK compared to North America.
• Siebel and Oracle: For the largest charities…
• And a few others which I know some charities have used:
• Zoho: Free and paid-for versions of their CRM and other online apps.
• Sage CRM (what was ACT! years ago) has a Windows and a SAAS solution. 
• Highrise CRM: SAAS software from the people who brought you Basecamp (although more oriented to contact management and maybe service delivery than fundraising).

As I said above, there are of course many other CRM solutions including a number which appear on Gartner's Magic Quadrant which do well in the commercial sector but which (to my knowledge) don't have any charity implementations. It will be interesting to see if any such systems start to also move into the sector and if any of those in the above list can challenge Salesforce and Microsoft CRM with leading sector offerings.

Why CRM Systems Are Like Icebergs for Charities

 

There is no doubt that the adoption of the generic CRM systems like Salesforce and Dynamics is increasing amongst charities and NFPs. But in comparison to the commercial sector we are still learning about the use of them. And in comparison to traditional fundraising databases (Raiser's Edge, thankQ et al) we still know less about them. Consequently, although there are definite benefits which the CRM systems bring, there may still be issues which we don't yet know about.

Bring on the iceberg...

My iceberg theory…
The fundraising database packages have of course been around for many years. Many organisations have implemented them, many people have implemented them at multiple charities and of course the suppliers have huge experience of them. And they have a more defined scope.

So we know many of the potential risks and issues with such systems (as well as the benefits of course) and when we start an implementation we can attempt to plan for and mitigate such risks. And even though there will inevitably be new risks/issues which occur during an implementation, I could have a good guess at some of the areas that some of those might occur within.

Whereas the opposite is true for the CRM systems - at least in the specific and critical area of fundraising. Because although there are of course existing charities who have implemented Salesforce, Dynamics et al for their fundraising needs, in comparison to the fundraising packages the number is still low. And those that have done may well have used different approaches to each other and very different configurations of such systems.

This is partly because of their newness, but also because of their flexibility, options, configurability and the breadth of functionality in the base platform. You (we) don't learn that overnight. And even as you do learn the system, so we have to apply that to get the best out of them for sophisticated and sometimes significant fundraising requirements.

And it isn't simply a matter of therefore finding an experienced CRM system supplier because they will also only have limited exposure to implementing their system for fundraising at charities and NFPs.

Hence the iceberg…

Because if it is true that 90% of an iceberg is underwater and thus we can't see it as we approach it, then the same could be said of CRM system implementations. In fact, it could be worse. Because at least we know that we can only see 10% of an iceberg above water, whereas actually we have no idea really as to how much of the "CRM iceberg" is submerged below water, waiting for us to hit it as we plough through the sea of implementation. I hope that in practise that we do know more than just 10% of what the potential risks/issues are, but I can't say for certain right now.

Whereas, with fundraising packages, one can almost turn that on its head (an inverse iceberg?) and say that we probably do know 90% of the potential risks/issues which could occur in a typical implementation of such systems.

So what can we do to plan the safe passage of the good ship CRM?
The good news is that although we may not know exactly what is coming to potentially scrape our bows as we sail past, we can have a good stab at knowing the sort of areas in which any issues might impact and thus even if we can't put a final mitigation plan in place for such risks, we can start now to consider how we should plan for them.

What do I mean by that? Well, let's take a complex income processing scenario. Maybe we know that our ideal requirements can be met by CRM system X only through customisation and coding. In which case, we can watch carefully as we start down that route, plan to take it slowly, test as we go along, re-test as we add further functionality, actually go-live with limited functionality and then build on that, and always have a back-out plan which might mean, say, that if we do find it is getting too complex/costly, then at least for the implementation we will decide to simplify the system itself and substitute the ideal functionality with off-line or manual processes instead.

Similarly, if we find that record volumes are causing a problem which we didn't know about for data migration, then we may decide to initially just migrate more recent data and then transfer older data more slowly over a period after we go-live. Or for gift aid claims, we could even have a third-party package ready to do some initial claims if we do hit a nasty bit of ice. And so on.

And overall we can follow good practise for any CRM implementation: get our requirements straight, make sure it is all documented for client and supplier, manage scope-creep, don't let shiny new whizzy stuff take you off down a path which you don't need to go down (at least not on day one), insist on good project management (internally and with the supplier), never forget your operational needs, look for true benefits and so on. Keep it all as simple as possible.

Reeling it back from the simile…
I realise that I am wandering off down the iceberg simile a bit too much, so let's reel it back to finish this post. What I am really trying to say is that we must not forget that some of the fundraising implementations already done on these CRM systems are still pioneers in their own way. We can do as thorough procurement processes as possible, we can learn as much as possible from commercial organisations who are more experienced in their usage and their business partners/suppliers, and we can learn some things from other charities who have already started to use these systems, but because of their sheer size and capabilities we must keep our eyes open and be ready if we hit a problem that we just hadn't thought of. Be ready for this as much as you can, and if that does happen then hopefully it will just be a slight scrape on our midship and we can avoid replicating the Titanic…

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.

Just what the heck IS a 360 degree view?!

 

"We want a 360 degree view of our supporters," or "We can offer you a 360 degree view of your supporters" are much-loved expressions these days. By charities and by CRM vendors. And when it's said, everyone nods their head earnestly and agrees, Yes, that's exactly what we need. And why wouldn't you? It sounds great! But does everyone really understand what they mean by a 360 degree view? It may sound simple/obvious (?) but is it really?

Let's have a look at a few definitions I found with a quick online search:

• Experian: "A 360 degree customer view gives a full picture of your customer and is essential for your organisation." Essential? Ooer.
• Aberdeen Group: "Buyers [donors] benefit from better service and efficiency, and sellers [fundraisers] derive improved loyalty and, inevitably, more repeat business from established customers." Okay, that sounds better.
• 360degreeview.com: "The 360° Customer View creates an integrated view of the customer – right across your enterprise. It gives you a business framework for integrating, enhancing, managing, and analyzing customer information, and allows for customized, phased implementations that deliver measurable business benefit." Wow, that sounds amazing!
• Purple Vision: "Everything you know about each supporter in one place." Ah, good - nice and simple.

So are they all saying the same thing? Well, yes and no. To answer that we probably have to first ask two fundamental questions: Why do we want a 360 degree view? And then, What data are we actually storing in order to provide one?

So, why would someone want a 360 degree view?
One of the most common data - and thus fundraising - issues for a charity is that there are so many data silos in an organisation; i.e. multiple databases and spreadsheets. And therefore, we can't see every contact point (often called "touch points" if you're being data-cool) which a donor or supporter has had with us.

And if that is the case, then: we might be contacting them without knowing specific things about them; we might contact them inappropriately; different people might contact them without knowing a key point about the supporter; multiple people might contact them at the same time for different reasons and risk losing, say, a key donation; we might not be maximising the most we could get from a supporter; we might not be keeping up with data protection/FOI requirements; we might not be able to analyse a supporter/groups of supporters as comprehensively as we could do - and as importantly as all that, we might not be treating the supporter as they would like to be treated.

These are all good reasons for potentially wanting a 360 degree view.

So what about the data itself?
But even if we want a 360 view and we know why we want it, then what should that view show? Does it really have to show "everything" about a supporter? And even if it should do, can it?! Can we ever see/collect all contact points?

I guess, ideally, yes it should show everything - that is the only way to really see a "complete" picture of a supporter. But how do we really know we are collecting everything? Is everyone in the charity entering every interaction with every supporter? Unlikely. Or even if they are, then it could well be on a local version of Outlook, a spreadsheet somewhere, a third-party online database.

I should also clarify "everything". A 360 degree view does not necessarily mean creating one behemothic, single database which is your only database where you store all your data. Very often, a 360 degree view (almost by definition of "view") will just contain key data sourced from multiple databases within your organisation - just enough to ensure it can do... whatever it is you are trying to do with the 360 system.

So do you really want one?
Could be. Their potential benefits can be great. And don't let my last few paragraphs stop you from trying to create your 360 degree view if you do decide it is right for you! Even if we can't definitely say we are collecting everything, then that isn't a reason not to try to set-up a 360 degree view if you see the benefits of having one for your organisation and your needs. Just be aware it might not be everything. Start-off with what you know and build it up as you find more sources, more people who might use it and as you identify more benefits from doing so.

Finally, assuming you do have multiple systems at your organisation - highly likely no matter how centralised you try to make a centralised CRM/fundraising database - then there is always the technical challenge of actually achieving a 360 degree view. That is not always as easy as one might hope.

Should I change my processes to match the database or make the database change to match mine?

 

This is a very common question I am asked: When I get a new database, should I change my processes to match the database and how it works, or should I make the database change to meet our processes? My views have actually changed on this over the last ten years and my own beliefs are now as follows:

First, It Depends...
First, there are a few "it depends" factors in this answer; the most important being:

• Why your current processes are as they are. In my experience, there are three common answers when I ask "why do you do process X that way?": (i) "I've no idea, we've always done it that way…"; (ii) "Because the current database makes us do it that way"; and (iii) "We've thought it through carefully and this is the best approach for us". Sadly, the latter answer is rare and the first two, and a combination/variation of those is more likely.
• Legal issues; e.g. gift aid, monitoring restricted funds etc. In these instances, the processes are going to have to reflect what is legally required anyway (although even here there could well be different ways to approach some of them).
• The type of database you are implementing; i.e. fundamentally whether it is a vertical-sector (traditional) fundraising database package, or if it is one of the newer breed of generic CRM systems. Although this difference is blurring a bit as I will explain below.

Why Wouldn't You Review Your Processes?
Secondly, when you implement a new database, whatever you buy, reviewing your processes is one of the most useful things you can do. As I said above, unless you already know you are in the "This is definitely the best process for us" category (which is rare), then this is a great opportunity to review why you do something, how, what's good about it, what's bad, what takes time, what could be automated, what you don't need to do and so on. And then you can take all that knowledge to the database implementation so that you can review the best way forward with your new system.

What if you are implementing a Traditional (vertical-sector) Fundraising Database package? e.g. Raiser's Edge, thankQ, Redbourn etc.
Many of these systems have been designed and adapted with many years of experience of what the NFP sector requires. And most which are still being sold today (if not all) are still selling and being used because they do the fundamentals perfectly well. And therefore, if you are buying into them as a software package, as a system, then it would seem to make sense to me to adapt your processes to how the packages have been designed. If you aren't going to do that, then why have you bought that package in the first place? There may be tweaks to do, but I wouldn't recommend changing the systems themselves except for the bare minimum and definitely within any parameters which the supplier suggests.

What about "generic CRM systems" such as Microsoft Dynamics and Salesforce, which you are implementing from a "vanilla" version (i.e. 'out of the box')?
These systems will give you an incredible amount of flexibility - which unfortunately is a double-edged sword. On the one hand, that means you can probably adapt the system to whatever process you prefer (within reason), so if your process review identifies some potentially great benefits by doing a process a whole new way, then this might be a great opportunity. Although that will also have the potential of higher cost, longer time, more arguments (sorry!) and a more complicated system than you might have needed. You need to be very good at keeping a lid on the amount of change you plan. And also: if you can do (nearly) anything then where do you start?! How will you know if your new process really is the best approach? How far should you go when changing the database system? And if you end up with vast swathes of changes then do not underestimate the Change Management you will need to introduce to your organisation. 

What about generic CRM system with a "fundraising/membership template"? e.g. Supporter360, Silverbear.
There are now quite a few "templates" which suppliers have created to sit on top of Dynamics and Salesforce in particular. In this instance, you are probably somewhere between still being able to change your processes if you really want to, but because the templates will have their own starting point, it would still be sensible to be using them as a starting point for reviewing your processes. Otherwise, as with packages, why buy them?

So What Is My Final Answer...?
My personal belief is to keep change as simple as possible, to use the software as it is supposed to be used as much as possible and if necessary, to start simple with the changes and fine tune them (or change them more dramatically) over time. i.e. Unless there are good reasons not to, adapt your processes to the software.

As I've discussed before, it is only after you really get to know your new software that you will truly understand what it can do, how and the benefits it can bring, so I wouldn't advocate spending huge amounts of time and money on it until you know what you really want from it.

Project Premortems: A Great Tool to Help Mitigate Project Failure

 

It is well known that CRM projects can fail. Just choose a number, any number: 35%? 60%? Whatever the figure really is, it's significant. So I was very interested when another sector consultant, Richard Collings, sent me a link to a fascinating article written some years ago now about a concept called the Project Premortem. And I liked it so much, I thought I should share it.

It works like this: We all know about compiling Lessons Learned after a project has finished (a post-mortem if you like). Instead, a Premortem is held at the start of an implementation (or even during it I guess). It starts by gathering project team members in a room and telling them that "the project has failed catastrophically". Then you ask them to imagine why that has happened. Everyone writes down why they believe the project has failed so badly and then you discuss it. And anything goes. People shouldn't hold back from airing their concerns and should not worry about offending others or upsetting senior managers etc. (Or: if you think that some staff might not be so open/honest with, say, a senior director present in the room, then I guess you could hold multiple such sessions).

The theory is that by doing this, it gives people a chance to air their concerns in a specific, safe environment, when they would not do so in normal working mode. And it makes us think differently too - more imaginatively (and maybe even as a bit of fun!) The scenarios given in the original article are excellent examples to show the sort of things which people might say. For example, the project sponsor "left during the project" and interest in the project waned thereafter; or one I might add: the supplier "under-estimated the work involved with a mission critical function" and therefore the whole project stalled by several months.

I really like this. I am currently working on a large CRM project and we have decided that we will definitely use this technique when we do kick-off the implementation.

As the original article says: "Although many project teams engage in prelaunch risk analysis, the premortem’s prospective hindsight approach offers benefits that other methods don’t… It also reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project." And as it goes on to say, "Moreover, in describing weaknesses that no one else has mentioned, team members feel valued for their intelligence and experience, and others learn from them." What a great idea - let's bring premortems to the fore!

---

Since writing this blog post, I have also heard the wonderful Freakonomics podcast air a recent episode in which the author of the original article, Gary Klein, discusses this whole concept. Well worth a listen.

The hardest part of a database implementation is the post-live period

 

This has become a little bit of a hackneyed expression these days. To say that the you won't experience the hardest part of implementing your new CRM system or fundraising database until it goes live. "That's when the real work starts," you'll be told. But for good reason - because very often it's true.

Why is this?

• Only at this point do you truly find out how the software is working for you. You can test forever and get as many users involved as possible during the implementation but it's not quite the same as once your staff are using the new system in anger.
• Your implementation project was hopefully funded correctly, but sometimes there is less budget or even no budget for future work after go-live. Yet, many implementations/systems will still require more work on them at that time. Some of that work may have been planned for a future roadmap but some may only have been decided during the implementation, for example, if you had to cut-back on (or change) the scope. 
• Resources (people) in particular will be 'back to normal' but potentially with different demands and requirements.
• There will be an impact on your users such as pressure on your database team, potential drop in productivity for some areas of use on the new system, processes still being optimised and so on. Read my recent blog post on The Immediate Effect of CRM System Change On Staff for a more detailed discussion on all that.
• There are bound to be things you didn't know about, you had thought you had tested but slipped through the net, that users didn't tell you correctly etc, and it's only when you go live that these issues will surface. Or things may have justifiably changed anyway, which will still cause issues.
• The enthusiasm and adrenaline which the implementation project had may wane. 
• The benefits which were envisaged/promised before the project commenced might not turn out to happen. Some may be understandable or yet happen soon, but others could have been over-sold or had too much expectation.

So what can you do?

• If possible, keep some of the implementation project team for 'as long as possible' after go-live. Three months is a decent rule of thumb for the average sized fundraising database; hopefully by that time most key issues will have raised their head.
• Prepare for some of the above as much as possible! At least those points you can prepare for, such as resources, expectations, impact. 
• Understand resource implications in particular.
• Have a plan for how to handle the new things you didn't know about - not the things themselves but a process for how to manage them when they crop up.
• Explain all this to your SMT early as possible in a project - even during procurement. Get their understanding, acceptance, awareness and support - whether financially or otherwise.
• And my personal belief is that doing a "Phase 2,3,4 etc" implementation is not the best approach. Instead, use a 'rolling development' plan with a roadmap. Read my separate blog on this: Why it is a Bad Idea to have “Phase 2” of a CRM Implementation (andPhase 3, 4, 5…)