GDPR Doesn't Mean You Need a New Database

Last week, Civil Society reported that "almost 40% of charities are considering reviewing their current CRM system with the launch of the FPS [and] GDPR." My message to such charities is: hang on, wait a minute, do you really need a new CRM system or fundraising database? Buying and implementing a new system is complicated, expensive and takes up plenty of your resources. So before you do that, there are a number of things you should do first:

• Talk to your current database supplier. This has to be your first course of action. What do they recommend? What are their plans? If you have a "fundraising system/package" such as Raiser's Edge, thankQ, DonorFy etc then such suppliers will still want to be selling their software to other charities now and post-GDPR, so they will need to ensure their systems are compliant or they won't sell anymore.
• If you have a CRM platform (Salesforce, Microsoft Dynamics 365 etc) then you almost certainly will be able to manage FPS and GDPR on them but of course it could be simple or more complex depending on your current design, if you have access to any IP (Intellectual Property) issues etc. So, again, talk to whichever supplier/business partner implemented your system. And if you don't have any such relationship and your in-house staff don't know how to change your platform then call on a Salesforce/Dynamics specialist developer - there are lots out there.
• Talk to other users of the same system that you are using. If the above doesn't get you any joy then talk to other charities who are using the same system as you are. If you've got issues then other organisations will almost certainly be/have been in the same boat as you. Maybe they have already found a solution and can give you some tips; or if not, then maybe you can all get together and put some pressure on the developer to get something done.
• Talk to other charities who are ready for FPS/GDPR and ask how they've done it. Even if they have created a solution in a different system/platform to the one you use, it is quite possible you can learn the concepts of what they have done and see if you can replicate that in your database. You could even look at third-party specialist solutions such as Wood for Trees' Consentric Permissions or Syrensis' The Preference Centre.
• And do talk to a qualified professional about what you really need for FPS and GDPR (i.e. a lawyer, compliance expert, a consultant specialising in this area etc). I have read and seen too much conflicting advice over the previous months and 'data protection' is unfortunately one of those things where many people think they know what is needed but many people don't really... And it is one area which you can't afford to get wrong.

Finally, if it turns out that you must change your current CRM system/fundraising database then don't rush it. Do it properly, get a formal procurement process in place, implement any new system with a correct timetable and budget; and if necessary keep your FPS/GDPR data in a separate system in a consistent format which you can import into your new system at a later date.

What we can learn from large, failed IT Projects

 

This is the first blog I am planning in an occasional series on lessons we can learn – good and bad - from commercial/public sector system implementations; looking outside the charity sector for best practice and alternative approaches we might take.

---

On Computing's website last week, there was an interesting article which says how “Accenture 'underestimated the complexity' of failed [£50m] national IT system for Police Scotland”. Whilst this is clearly on a different scale to all NFP CRM projects, there are some good lessons to consider regardless of what size project you are managing.¹ The following are some of the key lessons I think we can take:

“Early disagreements between Police Scotland and Accenture led to a breakdown in relationships and a loss of trust that never fully recovered”.

This is a classic problem and shows how important client-supplier relationships are and supplier management for the client. One of the few things we can say with (99%!) certainty is that something will go wrong sometime during any CRM implementation, and therefore if you have set off on the right foot and started developing good relationships with your supplier, then when the beep hits the fan, you should be in a better place to manage such instances far more appropriately.

“Within weeks [of the contract award], and despite 18 months of pre-award discussions, Accenture and Police Scotland disagreed about whether the proposed system would deliver the requirements set out in the contract.”

First, if you are really arguing about scope and requirements “within weeks” of a contract award, then you have probably not managed the procurement appropriately for your requirements, and/or you are kicking off the project in the wrong way. And/or you have not created an appropriate Business Case pre-project which should have declared what the benefits were which you were expecting, and thus what you were looking for from a system.

In addition to initiating the implementation correctly, it shows how difficult and yet how important your procurement process and any associated tender (ITT) document can be. You should be able to define the fundamental requirements and scope enough so that you are not arguing so early, but I am not convinced that a long, complicated ITT document would necessarily mean you would avoid such issues.

For most CRM projects for charities, the procurement process should be about finding the right supplier, the right business partner for you, and their software/solution is part of that. But I do not think that, for most charities with their resources and needs, that a tender document can be certain to (or even should) cover the whole scope, encompass all functional and non-functional requirements, and do it to such a level that no disagreements will come later.

There are increasingly good reasons, therefore, especially for larger CRM projects and especially when building on CRM platforms, for doing an initial ‘discovery’ phase after the initial contract award which will spend more, detailed time detailing what is required from the rest of the project: what, when, how and who is responsible. To a certain level at least. And at least so that the client and supplier know more than they did pre-sale and so the supplier can refine and provide more accurate cost/time estimates on the agreed scope/requirements. Even if you are planning an Agile implementation thereafter, this ‘waterfall’ part of the implementation is well worth while.

“The programme was complicated and highly ambitious [and] the idea was to merge more than 130 legacy systems.”

Any IT/CRM programme where you know it is going to be ‘complicated and highly ambitious’ needs to be thought through more carefully before implementation. Can you really manage such a project in ‘one go’? Should you instead break it down into blocks/smaller sub-projects (regardless of project management methodology), thus considering how some aspects of it could be de-risked and the different blocks made less complex?

If you are going to merge several/many legacy systems, then this is a wonderful opportunity to break down the implementation into multiple blocks, prototype, do early go-lives for limited users/functionality, learn lessons as you go along. Even if those lessons show the project will be more complex than first thought, then get this lesson sooner rather than later.

You can still be considering ‘the overall’ project at the same time (e.g. considering how you can do merging/de-duping from each legacy system into one, looking at overall visions/benefits) whilst you are doing one or two of the early migrations.


"The two parties had initially believed that the majority of the system could be based on an existing IT system that Accenture had delivered elsewhere. But… as the design and development process developed, it became apparent that Accenture would need to develop significantly more than what had originally been anticipated."

If a supplier says the majority of their system can be based on an existing system they have, well, if that is the case, couldn’t you be shown that system up-front? And if so, then both sides could tell far sooner (i.e. pre-sale) if it really is viable to be re-used? Similarly, if it is that good, then couldn’t a simpler ‘fit gap analysis’ help in the first place? If that shows it is a larger gap than expected then, again, find out early.

If you are buying a CRM system based on a platform and you are being told there is 'an existing system' you can use, then ask for more evidence, do more work on investigations, plan how you are going to run the project accordingly and ideally, consider if the contract can reflect that.

And if your supplier does not have experience in your sector, with your requirements, then although that certainly does not necessarily mean that they could not do it, it does show that you need to be more careful about the procurement process.

“After Police Scotland tested the system, Accenture estimated that meeting the requirements of the contract would take an additional two-and-a-half years, with the live date pushed back to April 2018, almost four years later than originally planned. [And] Police officers found 12 critical errors that made the system unusable, with 76 defects in total that required more work.”

This shows that ideally you do not wait until UAT to test such fundamental issues. Ask how the design is being done earlier. Are there critical factors you can test earlier, even in a waterfall project? An ‘agile’ or iterative approach (even a hybrid waterfall/agile methodology) can also help mitigate some of the risks of doing UAT close to a go-live which might mean that only then will you find issues that could push back go-live so significantly.

“Accenture underestimated the complexity [of the project].”

This sums it all up and it is sadly something I have seen on a number of charity CRM implementations by (large and small) suppliers and business partners. Maybe they don’t know your business/sector well enough, maybe they have under-quoted even if they do know it, maybe you as a client didn’t explain the complexity well enough. I hope that all the above points should help mitigate some of this possibility.

---

1. I want to emphasise that this blog post is in no way suggesting that only Accenture have issues such as this! Clearly you could have the same issues with any supplier. And, of course, I don’t have any knowledge of this specific project except for what the article provided – but I do think there are generic points we can learn.

12 Key Lessons From My Last CRM Project

On the twelfth day of Christmas, my truelove gave to me... Twelve Key Lessons I Learned From Managing My Last CRM Project

I thought I would finish this set of blog posts with a quick-fire set of some of the most important lessons I learned from the last CRM project I managed. Each point really deserves its own dedicated blog post, but I hope they provide a succinct set of tips in themselves:

• Configuration not Customisation where possible: I have blogged about this before and it remains true. The more you can Configure and use the software's built-in tools and GUI to configure and define your system, the better. Each bit of Customised code will add cost, time, risk, pain and something you should try to avoid unless you can see real benefits, at least during implementation.
• Don't try to re-create your existing database: It is so easy to go down the path of replicating exactly what you do now but just in a new CRM system, when what you should be trying to do is use the functionality and approach and benefits of the new CRM system. If you have bought system X then use it as it was meant to be used. Long-term that will set you up so much better.
• Yes, ask users what they want, but then start with a simple base configuration and go from there: i.e. don't try to do every little single thing which users ask for, don't try to change every form on every screen for n different teams, don't bend and change the software in complicated ways when you are still learning and building it. Instead, get the basic requirements, use the software in as simple way as possible to get a starting point and then show the users that - if there are then things which you really have to change then you can consider them at that point or even post-live.
• Don’t under-estimate the challenge of data integration: Integration is hard, no matter how you do it. Think of all those external data sources you need to import, that other system you want to share data with/update from your new system. It takes time, effort and money. Some suppliers may have starting points for some things such as JustGiving etc and that's good, but you may still need to change things.
• Treat reporting as its own workstream: Reports are always one of the things in a project where you start off with great intentions and then as the project goes on, you can find they slip down the order of priority. I would recommend managing them in a dedicated workstream, with a dedicated member of staff leading on them. Remember: reports are one of the key reasons you have a fundraising/CRM system in the first place!
• Work hard at supplier relationships: At some point in your implementation, it is highly likely that something will go wrong and you will need to discuss something painful with your supplier. The better your relationship with your supplier at that point, the more likely you will be able to come to a mutually satisfactory conclusion. It needs work but it's worth it.
• Consider a Product Owner/Solution Owner: In a large CRM project with a significant timeline and budget, consider including a role of Solution Owner (aka Product Owner). This is a role for someone who understands not only the charity's requirements and strategies but also fundraising/charity requirements more generally, as well as CRM software and technology. The reason for this is because the implementation of sophisticated, flexible (and often expensive) CRM software systems is of course not just about the software but about building/configuring and using it with the people and processes in mind - and understanding the whole approach, design, dependencies and implications of design. The role provides a central point of contact for design understanding and fundamental decision making.
• You will always need more people on your team: As the project progresses, you will no doubt find that you could do with more people working on your project, although it could be that you don't know all the exact roles when you start the project. So think about this up-front, budget for it and bring on some roles as you go through the project. Ideally, have a budget for future roles but have an agreement with your project board that you can define the actual roles later. And backfill if you can - always good to up-skill both the people you bring on to the project and the staff who step-up to do the BAU whilst those other people are on the CRM team.
• Think about the post-live structure of your database support team ahead of time: It could well be that the roles you have in your current database support/CRM team will be different to those which you will need with your new CRM/fundraising system, especially if you are moving from a traditional/proprietary software to a CRM Platform,  Think about this as far ahead as possible and make plans.
• You can mix-and-match your approaches to cost within the project: There is always the question of whether you should go for a Time and Materials (T and M) or a Fixed Cost budget. In fact, you could mix and match even in the same project. For example, some of the development work might be T and M but the data migration could be a fixed cost. Etc.
• Post-Live: Use a Roadmap, not Phases. I will point you to my older blog post on this as the principle still stands. I believe that having a roadmap approach to post-live development is far better and more efficient than the concept of Phase 2, Phase 3 etc.
• The importance of fun in internal comms: When you are engaging all your users, staff and stakeholders with your regular communications (which you have planned, yes?), then think of the one word which many people would describe such comms. Go on, close your eyes now and do it... Okay, got that word? Was it... "Boring"?! Sorry, that is often how it is! So make your internal comms more fun: whether it is with more innovative emails, interactive demos, screens in the staff room, lunchtime meetings with food, competitions with chocolate... It doesn't matter so much what it is, but try to think what would make you read something you didn't want to read and do that.

Supplier Catchphrase Bingo!

On the eleventh day of Christmas, my truelove gave to me... Eleven Things Which Suppliers Say at Demos Which You Can Use to Play Supplier Catchphrase Bingo!

So this is mainly for fun but with a serious(ish) message. The next time you have a software demonstration from a supplier or set of suppliers, listen to their spiels and see how many of the following phrases they say which you can tick-off in each presentation...

We offer the best support in the sector	Our system provides a 360 degree view	We want to be a partner with you
This is a Game Changer	You must be in the Cloud	Our system is completely Future-Proofed
We’re specialists in sorting out other suppliers' problems	You don’t need any documentation	(We do) Agile...
You should never buy… (e.g.) a CRM Platform/proprietary fundraising software…
X isn’t difficult (e.g. data migration, integration, reconciliation with your finance system, security)

Of course, some suppliers may say some of the above things and genuinely mean them. Some companies of course implement CRM systems using an Agile project methodology and may well do it well (I'm just sceptical of what exactly they mean by that or if it is just a buzzword they are using); some will truly believe that Cloud is best (for them at least); and some may well have sorted out another supplier's "problems" at another charity - but by the time you've met a few, each one of them will be claiming they have sorted out another's problems...

My point here is not to ridicule suppliers, but to emphasise that they are, understandably, selling to you. You need to ask questions, dig down into specifics, request examples, ask them to show you specific elements of their software, talk to their implementation and support staff, have second meetings and so on and so on.

And always take with a pinch of salt any company that says their software is completely future-proofed.

Differentiating Suppliers of the Same Software Platform

 

An interesting challenge is arising on CRM platforms. With more and more companies producing 'templates' for fundraising and membership solutions on the same platforms (mostly Dynamics and Salesforce), I am finding that I see quite similar looking software from different suppliers. Which leads me to ask myself: if the platforms are that good and are right for my clients, and the software is starting to blur into the same sort of solution, then how do I distinguish between the different offerings?

First, it's about the supplier
What this shows straight away is the importance and significance of the supplier themselves. i.e. their approach to your project, their empathy with your organisation and staff; the people they employ; their sector knowledge. The added value they can bring to the project and to your organisation. All the usual sort of stuff I discuss frequently on my blog, but with a different level of emphasis because of such a need for comparisons and differentiators.

And that to me is still the most important thing.

But it is the software too
There is more you can also do to look at the software more deeply. Even if it looks similar (which it probably will because it will be on the same platform) it will of course be different when you look closer, especially in the areas of fundraising or membership. Some of the specifics you could consider include:

• How are the companies actually presenting the core data which you want to see? Is it truly intuitive? Is there flexibility in its presentation? Have they understood how fundraisers want to see and use such data?
• Look especially more deeply at the most critical parts of the software. For most charities who are doing fundraising this will be the income management. i.e. If a supplier is offering you a solution with some sort of template to manage your cash donations and regular donations, then how have they structured that? Have they used the platform's standard entities? Have they used custom entities? How have they created a system where you can record a pledge and its instalments? How have they created a system which enables you to create a direct debit mandate and then record all the future payments against that? And do they really understand regular giving itself? And how about reporting of this area - that takes some thinking about. This will start to show-up differences and suppliers' comprehension of this crucial area.
• What about batch entry of income? What about the data entry of more complicated aspects of some fundraising data - e.g. in memory relationships, corporates and their contacts?
• How have they actually coded the system to process direct debits? Can they manage high volumes - not just your current levels but if you increase them too?
• Do they understand Gift Aid and how have they linked their system with HMRC's Charities Online?
• How have they optimised the more common CRM elements for charities' needs? e.g. opportunities, leads. Have they shown how you major donors and HNWI fundraisers could get the most out of such systems?

In addition to all that, you also need to consider how different suppliers are considering the future of your software. Do they see it as a 'product' whereby they will be providing functional upgrades in the future? Or is it just a system which you are buying 'as is' and then build on enhancements as and when you want to? Neither way is right or wrong, it's down to your requirements and wishes. And depending on how you want to develop the system in the future, consider also the intellectual property (IP) aspects of the solutions.

Finally, you'll notice I haven't mentioned cost. So, yes, cost does of course distinguish and separate suppliers, but it's never as simple as saying that the cheaper solution is the one to go for. There is so much more to cost than that! Have a look at my blogs on cost factors and indeed, everything else about procurement.

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.

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?

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

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.

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.

The Benefit of Documentation When Implementing New Databases

 

So: If you're reading this blog post and wondering why I am even bothering to write it - because of course documentation is important - then great! You can stop reading now! Go and have a laugh at today's Dilbert instead. But if you do doubt the benefit of documentation in database implementations (or if you like the sound of documentation lite…) then read on… Because this is why I think documentation is important:

• Structure for project managers: It gives the people running the project structure - it helps them see what's what, where we are, what we are doing, who's doing it, what needs to be done and so on. I know these are easy words to write and perhaps not tight enough (especially for a blog about documentation!) but this is the heart of the benefits which documentation brings. As a project manager it gives me what I need.
• Structure and assurance for project boards: Following on from the above point, it gives your project board the same assurance and support.
• Accountability: This is important. It means that we have a written record as to what was discussed, decided, agreed (or not), for who, by when and so on. It's especially useful for when disagreements arise between a supplier and client, as we can then have at least a starting point to discuss.
• Blueprints: For projects which do require some up-front consideration of how the database is going to be configured, especially where a third-party supplier is doing that work, blueprints are pretty much essential. This is what was decided by client and supplier, this is what the supplier will deliver, and this will help formalise the project and avoid (a set of) arguments later about this.
• Data dictionaries: I wrote a blog recently about the benefit of data dictionaries - I still believe all that.
• If someone leaves… I've been brought into projects where an organisation is half way through a database implementation and I have needed to catch-up quickly with where they are. The better the documentation - i.e. the more poignant it is, not necessarily the amount of it - the better it is for someone new to be able to get up to speed.
• Agile methodology: I know some Agile evangelists believe that documentation is not so helpful because things can change so quickly in the next sprint anyway. I guess this is something that every Agile implementation needs to consider: is there some space and reason to have relevant documentation? Or do we agree it's not necessary. It might worry me sometimes…
• The more attentive of you will have realised that much of what I am promoting is to do with "clients and suppliers". Yes, that's true. I do think this is where documentation can help. It keeps everyone on track, maintains a level, fair playing field for both parties and I think instils good practise in implementations.

Then of course there are project plans, risk registers, communication strategies, data mapping tables, file formats for data integration and so on. I realise that even fans of documentation lite might see these types of documentation as more useful, but that doesn't always seem to be the case in my experience. Personally, I think we need them.

And just to finish with a couple of caveats: Documentation does not have to mean wreathes of paper - a well structured, online system of "documentation" can be just as useful for many of these issues. As long as it is structured, searchable, auditable, accessible then great, I'm all for that. And I am not saying that you need to follow PRINCE2 to the letter and create Product Descriptions to the nth degree - i.e. I'm not saying you should have documentation for documentation's sake. I realise there are times when keeping documentation to a minimum - or rather, to the amount appropriate for your organisation and your implementation - is right. But I still think documentation is needed.

Why I want charities to spend money on suppliers' professional services

 

There sometimes seems to be a keenness amongst CRM/fundraising software suppliers to tell charities that they can implement their software by only spending a bare minimum on their professional services - or even none on some occasions. When I see this, I worry. Why? Because I want charities to spend money on suppliers' professional services. And there are good reasons for this:

• First off: I think that a good supplier offers many benefits by providing professional services. They shouldn't just be a 'software company' that is giving you software and expecting you to use it just like that. I want a company who understands our sector, who gets fundraising, who can provide added value with their services. This is good for the implementation and good in the long-term. Those are the companies who will want to work with charities and enhance their software for charities over time.
• Continuing that theme, I do think some suppliers undersell themselves in this way. I have met knowledgeable and smart people working for suppliers who I think could bring so much to a database implementation at a charity. Why wouldn't we want that?
• The suppliers are the experts at using their software - they know their system. After all, how do you know what is the best way to do something in the supplier's software if you have only just started to use it? What is best for your charity and your situation? The money you spend with them on their services should ultimately save you time and effort, ensure you are set-up better for your fundraising/services and mean you can raise more money/dedicate more time to services.
• You need people to help you. Someone has to. And either you buy-in contractors and specialists or you use the supplier. Implementing fundraising and CRM systems is not easy - it costs money. (Even if the software is free!)
• And then there is data migration… except for the very smallest implementations, you are always going to need to get your data from your old system into your new system, and unless you have lots of capacity and time at your charity, and unless you know the new system well, then the best people to do this are those working for the new supplier.
• If you are told by a supplier that you don't need professional services from them, then what are such companies actually offering that is so simple that you can apparently use it almost of-the-box with no work needed, yet so powerful that it can manage all your requirements? That's how it seems to me that some salespeople present their systems and I'm just not sure that's feasible.
• Are the suppliers not providing any project management services to manage their side of the implementation?
• I suppose there could be a caveat to some of this if you are a really small charity – although even then, as I have said before, such charities won’t have the in-house skills to be experts so they really need a supplier to help. 
• The only situations where I think you might not need to spend money on a supplier's professional services are (a) where you might have a different sort of approach with open-source systems such as CiviCRM if you really have in-house experts, but for many charities they won’t and therefore they will still need the Civi Experts; and (b) similarly, if you buy something such as Salesforce, kick-off with their vanilla version and, again, you do have in-house staff who already know the system and who could then do much of the work themselves. However, even in this scenario, such staff are likely (at this point in time) to still have limited exposure to implementing large CRM system at NFPs, so there could still be the benefit of using the suppliers' professional services even in these instances.

I’m just not sure what I think about suppliers who say you can do it all yourself and don’t need their input. They are either amazing or maybe, er, not giving you the full picture…

Does it matter if a Fundraising database supplier doesn’t understand Fundraising?

The more I work on fundraising software procurement and implementation projects, the more I ask this question: how much does the supplier's experience of fundraising matter?

For years, this hasn't been such a relevant question, at least when purchasing packages as opposed to bespoke systems, because most new fundraising database systems were supplied by companies who either specialised in the sector or who at least had a dedicated department who did so. Of course one would find companies and individuals with more or less knowledge or experience but nearly all had some. And also you could see the evidence of some of their claims with their software.

But now with the prevalence of the newer CRM systems, this is a more poignant question. Now, in theory, any company who sells Salesforce, MS Dynamics and the like, can at least promote themselves as a partner who can provide a fundraising solution. So does that matter? What are the problems with that? Or actually, are there even benefits of using a supplier with less sector knowledge?

The reasons that a supplier's knowledge does matter are comparatively easy to identify:

• Charities are different to commercial organisations. That might sound an obvious thing to say, and in some ways it isn't 100% true for fundraising - after all, we're managing contacts, building relationships, running events and "selling" in the same way as a business is, just philanthropically. But there are of course many distinct differences and approaches - and one of the most significant is that several commercial CRM suppliers I have worked with have been amazed at the sheer breadth of activities which charities manage in comparison to their size. And thus their internal complexity increases. This isn't always a good thing of course, but it's a fact.
• Any supplier in any sector who can bring experience of working with your peers will surely add something to the project. They won't just be implementing software, but should be able to suggest ideas and approaches that have worked for other charities.
• You don't have to explain what Gift Aid is, how direct debits work, why relationship fundraising is important, who JustGiving are and so on. They will know that already. And why should you have to pay a company to teach them all that?!
• They won't try to take you down a route which isn't right for a not-for-profit organisation, or overly try to enforce their concepts from other sectors which they might believe are right but which they don't actually have experience of doing in the NFP sector.
• Many of the traditional fundraising database suppliers have ex-charity employees in their implementation and support teams, and that can be a great benefit as they can bring real-life and hands-on experience of using that system.
• All this should hopefully increase benefits, reduce risk, reduce the project timescale and as a result, keep costs down.

That said, one would hope that any company who understands CRM, has good business analysts, can empathise with your organisation and bring great technology skills should be able to manage a lot of the above even without specific fundraising sector knowledge. And in some instances that can be true. Sadly not always, but sometimes.

On the other hand, I also have to say that one of the great things which has happened primarily as a result of the newer, generic CRM systems now flooding the charity sector, is that we are getting a whole new view and different insight into charitable activities. I have been saying for years how insular we can be as a sector (myself included on occasions!) and so surely I should celebrate newer entrants with fresh thoughts and ideas?

So what can a company with less fundraising experience bring to the table?

• They can challenge a charity's pre-conceived ideas that the only way to do something is how they do it now. Okay, a fundraising-knowledgeable supplier should be able to do the same, but as more of an outsider, a company with less knowledge can ask what might seem like basic questions - and some may well be! - but some might just make us think that little bit differently and hence start to get a whole new advantage in an area.
• They will bring good business practises which some of the sector may not have followed before.
• They could bring commercial ideas to the table. This may be something of an anathema to some organisations, but for others, it might even help fundraising.
• They will have a wider knowledge of multiple sectors and industries, and be able to provide input in all sorts of ways which we might never have thought of before. I have always thought that the fundraising technology sector should be able to learn more from other businesses so this is an opportunity to do so.
• They should - the ones you invite as a possible supplier - "get CRM". And that's definitely a good thing.

My Conclusion

I am a bit torn. I already embrace new CRM systems into the sector and I really want to embrace the suppliers with them. And some are good - some very good. But some have their issues too.

Not that the traditional fundraising database suppliers are perfect - I've worked with enough to see holes and problems with their approach, fundraising knowledge and understanding of technology.

But on balance, I still need to be shown by any "non-sector" supplier that they do know, have knowledge of or can learn about fundraising and the charity sector. I will always remain open and encourage suppliers to provide that to my clients and me, and if they can do, fantastic, they're in the melting pot. But if they can't then I need to question if working with them is going to help or hinder the fundraising database implementation.

Not blaming the client: the supplier's responsibility when implementing CRM systems

 

Every now and then on database implementation projects, I'm aware of suppliers who try to pass the buck once too much and maybe try to overly blame the client when the project isn't going well. And I have one fundamental issue with this: the supplier is the expert who will have implemented dozens and maybe hundreds (thousands?) of similar systems - the client will hopefully only do this once every five to ten years. So doesn't the supplier have an additional responsibility?

Now. I do realise that it isn't quite as cut-and-dry as that. I know of charities who have blamed the supplier when things have gone wrong, or accused them of things when I am pretty sure that the supplier would never have advocated such an approach. Or the charity itself should have considered something, requested something, put something in place or, most commonly, committed more and/or more appropriate resources to the project. And yes, it should be a partnership between supplier and client. So I completely accept that the supplier cannot be and should not be responsible for all aspects of the project.

But I do get annoyed when a supplier blames far too much on the client. Or when they do not explain things better to a charity, when a supplier goes off down a route of development which clearly isn't appropriate for a charity, or when the charity is expected to 'sign off' design issues early on in an implementation and when the implications of any decisions are not truly understood by a charity - and yet the supplier should have the experience to really emphasise more to the charity just what they should be doing and what might happen if they don't do that. And if the charity still decides not to follow their advice, then fair enough. But the supplier has to take some responsibility.

The trouble is, as I said above, if a charity is only implementing a fundraising database/CRM systems once every few years, and even if they are employing a database manager or similar who has maybe done a similar implementation once or twice before, they still won't have the experience which the supplier has. So how can they really understand the full implications of any decision unless the supplier makes it really clear to them?

On the other hand...
So if I am saying all this then it is probably only fair if I also address one question which a supplier could quite understandably ask me: if a charity does ignore their advice then what should I do? With the extreme question, should we even walk away from the project?

Clearly one hopes it is a rare thing for a project to reach such a point that a supplier has to consider this. I have had a wee rant above about what I believe suppliers should do, but I also hope that most of the time - with good, reputable suppliers - this just means that if they do see a charity doing things the wrong way then they at least discuss this with the client. If necessary, one might want to pause the project, try to get it back on track, work out how it can be managed better (by both sides?) as it continues, but I would hope that all such considerations are held before anything more drastic is done.

And walk away? There would of course be all sorts of contractual issues, unless one side just accepts the lost income, but it is an interesting ethical question. I'm sure we would all prefer that the supplier - and client - worked hard to turn the project around, but yes, maybe there is a time when it is right to sever ties mid-way through an implementation. But that's tough.

Trying to avoid this in the first place
So what can we do to try to avoid reaching such an impasse? The first thing the charity can do - and possibly the supplier to - is undertake a through procurement and, if appropriate, an immediate design/discovery phase after that with the preferred supplier. This may open up areas which are currently misunderstood, show other areas which need to be hammered down, raise issues of resourcing, budget, responsibilities etc. I know several suppliers who insist on such phases now in CRM projects.

Designated project roles can also help; a project manager on the client's side is of course important and even a Solution Owner role might be another answer; early and comprehensive training of the project team could help; documentation showing deliverables and responsibilities; or documentation full stop can help. If we have good, agreed, well structured documentation showing what has been requested, agreed, designed, planned, deferred and so on, then that in itself can help prevent (some of) the 'but you said...' issues.

Even implementing using agile project management can alleviate some of these issues, although I have equally found that agile can be an excuse that just because a decision was made a few sprints ago, now we have to change it because 'new requirements' have come to light, when in actual fact it was just a poor decision/recommendation in the original sprint...


But I still sometimes have to come back to the supplier's responsibility as well. As I say, they are the CRM experts, they are the ones who know what has gone well and gone badly before - and those that understand this will be the good ones who will succeed in the sector. And we all know how important reputation is in the sector. That alone should be enough to encourage them to uphold this approach.

CiviCRM: A great example of Open Source Benefits for Charities

CiviCRM is almost certainly the NFP sector's leading open source CRM system. And if you want an example or two of why this is, then, aside from its standard functionality, the following should explain a lot: Just recently, Leukaemia and Lymphoma Research, who use CiviCRM, wanted to integrate Civi with JustGiving and so they developed an integration piece to do this - and they have made that available for free for all other users of CiviCRM. Prior to this, the recent HMRC Charities Online gift aid update meant that changes were needed to the existing CiviCRM Gift Aid functionality, and again, Leukaemia and Lymphoma Research developed the changes required and made them available to the Civi community. And even before that, when there was no Direct Debit processing or Gift Aid functionality available in CiviCRM, a third-party Civi partner, NFP Services, developed these features - although they did this as part of a paid-for development - but thereafter, those functions are now available to all other Civi users.

And if a CiviCRM user wants a new function which hasn't yet been developed in the core software then, although they can of course enhance the system in-house as Leukaemia and Lymphoma Research did, or pay a developer to create that for them - and there are a number of CiviCRM approved service partners here in the UK as well as worldwide - they can also add it to the 'Make it Happen' campaigns on CiviCRM's website where ideas can be put forward and multiple Civi users can contribute in order to fund the development.

This shows the appeal and benefit of CiviCRM to some charities: collaboration and joint development (as well as good software). And shows the all the great things about the Open Source community - and yet it also highlights some of the dangers too.

The benefits are clear: open source is free software, although please remember that it is just the software which is free; the implementation, developments, training, data migration, any consultancy/project management etc, and of course the hosting or in-house servers, all cost money. And it has a great ethos for charities, and an ever-growing and broadening community using and supporting other users. And by its very nature it tends to attract developers who believe in not just the software but the whole approach.

But the fact it is not driven by a commercial organisation means that when statutory or regulatory requirements change (as highlighted above), then a user and/or the community needs to get the software updated to manage that. And although the software is constantly being developed and enhanced, it doesn't have the same financial clout which some of the larger commercial CRM suppliers have and as it isn't a dedicated fundraising database then there is a different incentive to the 'traditional' fundraising database suppliers. Of course, this approach is the very thing which encourages some organisations to use CiviCRM (!) and as it states on Civi's website, "CiviCRM’s development roadmap is primarily generated from the ground up".

CiviCRM has a lot going for it. It is one of those systems where it feels there should be a natural, cultural fit with the NFP sector. It has decent functionality and it is growing its user-base here in the UK. It isn't a "traditional" fundraising database system, but neither is it a "generic" CRM solution (a la Salesforce, MS Dynamics etc). What it is is a "CRM" solution which has been created specifically for the nonprofit sector, and as such, with in-built functionality specifically created for charities. 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's unlikely, of course, that CiviCRM will ever be as big as the major CRM players because it is sector-focused).

And all this on a platform which is flexible and where even non-technical users can create reports, add features such as new fields (and tables), adapt forms and so on. Try that on some other systems…

When I discuss different database options for charities, I often pigeon-hole software suppliers as "traditional fundraising database solutions" or "generic CRM solutions" - CiviCRM is neither but that is no bad thing, and if you are considering a new CRM system or fundraising database then putting CiviCRM on your radar could be well worth it.

How Not to Buy Software? The Astonishing Stats Provided by Capterra

Software resource portal, Capterra, has recently published a report on the findings from a survey they ran which examined how organisations make decisions when buying software - and it makes interesting and sometimes scary reading. For example, "1/3 of software buyers don’t demo any solutions before they make a purchase" and "another 22% just choose the first software they look at!" And very interestingly, "the more demos and options that software buyers considered, the less confident they were in their selection." Hmm.

And this survey included nonprofit organisations in its statistics…

Who gets involved with purchases?
The report details the types of staff involved in the buying process:

• CEO/Presidents were involved in 40% of the software purchases - and this level of person is most likely to be involved in software which includes "marketing" (read fundraising) and one of the sectors which they’re more likely to be involved in software purchases is the nonprofit sector…
• IT Personnel were involved in 55% of all software purchases. Although it does also say that one of the software solutions IT staff are most likely to be involved with is Database Management, which I hope means that more than 55% of database purchases involve IT staff to some extent…

Interestingly, the Most "Diplomatic" Software Purchases included CRM Software, where "job titles across all levels of the organization were equally represented in the software decision making process." I'm glad to hear a wider range of staff are involved in CRM purchases, but I'm not sure if I really want lots of people involved in the decision making process. (More about that in a future blog post...)

Of course, what is harder to quantify is what "involved" means for a purchasing decision. If it means being kept in touch and maybe ratification then that is very different to attending demos and making a final decision.

What do people look for in software?
One of the most interesting sections of the report is a table showing "The Most Important Factors in Software Selection". It's very interesting (some might say encouraging?) to see "Low price" and "Vendor's market share" so low in the table, and despite all the cloud-hype, "platform" is still only #9 on the list. Both "vendor responsiveness" and "software reputation" come above that - which shows how important the supplier itself is to the buyers.

Perhaps unsurprisingly, "Features/functionality" is listed as the most important factor. It's hard to get away from that. This is of course one of the downsides of "lists" like this - yes, functionality is important, and, for example, I often drone on about how it doesn't matter if software is/isn't in the cloud if it can't operationally support a charity - but I always encourage charities to consider features as just a percentage of a decision making process. Equally (more?) important are all the other issues such as supplier support, ease of implementation and so on. So it's not quite as simple as saying that the #1 factor necessarily outweighs others.

What can we learn from all this for a UK charity looking to buy new fundraising or CRM software?
Can a survey taken across a variety of industry sectors in the US also apply to CRM software selection for UK non-profits? Well, 50% of the survey's respondents have less than 100 employees in their organisation and 64% less than 500, so that's not so far off. And the "important factors" list tallies with my experience of UK charities' processes - not that that makes it right unfortunately. (And if you look at Capterra's website, then the Fundraising & Membership Software lists include names such as Blackbaud, Donor Perfect and Wild Apricot, so these are not insignificant companies).

But there is another table in the report which nicely sums up what organisations need to understand more, consider more and where they can do with help - and that is the Most Difficult Parts of the Software Selection Process table, which lists 3 key issues:

• Getting a clear picture of how well each possible software option could meet specific needs;
• Being able to make comparisons between software companies/vendors;
• Absorbing and understanding the information available about different software solutions.

This therefore shows what you need to be doing and considering when buying software. Which, I realise, can be easier said than done. Which is why I hope that posts elsewhere on my blog give guidance to how you can address such concerns. And there are other great websites with other useful resources such as LASA's Knowledge Base and TechSoup; and the various sector events held by the Institute of Fundraising, sector media and exhibition conferences, all of which can also help - look out for the free seminars at some of these. And use your peers too - the experience of other charities does help.

There are many more fascinating and enlightening stats in the report, not all of them so relevant to all the work we do in the UK fundraising/CRM software market, but still a great read!

---

You can download the full report from Capterra's website.

Salesforce and Microsoft Dynamics for Fundraising: Are We Nearly There Yet?

It's been over 18 months since I last gave my 'state of the nation' view on the shape of the (now not-so) "new" CRM systems in terms of their applicability to fundraising technology needs, and a lot has happened since; so here's my latest opinions:

Who's using Salesforce and MS Dynamics for Fundraising?
It's noticeable that even in the last 6-12 months, there has been a shift in the mindset of some mid-large UK charities which, for the first time, is starting to pay dividends for the CRM suppliers. It's well known that Barnardo's are the first large UK charity to be implementing Salesforce for fundraising, Greenpeace International are now doing so too, another national UK charity is implementing Microsoft CRM Dynamics for their supporter relationship management system with another to start soon, and Leukaemia and Lymphoma Research have been using CiviCRM for a while (as have MSF outside the UK). And there are more in the pipeline for all these systems. Plus, of course, there are many more NFPs using these solutions for non-fundraising applications.

So why now for larger charities?
Although Salesforce, Dynamics et al have been adopted by charities for several years for non-fundraising solutions, and although smaller charities have been using the systems for their fundraising needs, why are we now seeing the mid-large charities start to take this route? There are probably a number of reasons:

• There are naturally less such projects for the larger charities and those organisations that are/have been looking have taken until now to have made decisions - equally, such projects are not cheap, so there are of course fewer of them.
• It has still taken until recently for the sector to truly believe, and to have it really shown to them, that these CRM systems can provide the fundraising functionality they need - for too long, suppliers had just been saying "yes, we can do it" without any real supporting evidence or suitable background to make the larger charities comfortable. They aren't all there for all areas of fundraising but there's been huge steps.
• Inevitably, some charities have waited until someone else took the initial leap into this space, but with Barnardo's, Greenpeace and others now doing so, it makes it that much easier to see the benefits and possibilities.
• It has taken some time for the resellers and business partners (implementers) - not the software suppliers themselves - to show their credibility in being able to sell and implement these systems for fundraising. Not in terms of technology but in terms of showing the charities that their in-house fundraising knowledge, and how technology can be used for fundraising, is good enough to support such implementations. That said, I think this is still a challenge.
• The acceptance of the cloud is growing every day in the NFP sector, and there is less concern over security than there used to be. This has probably never been such an issue for IT staff at charities, but it did un-nerve trustees earlier in the cloud's evolution.
• Amongst the "templated solutions", the functionality itself has improved.
• The CRM software vendors and their partners are darned good at marketing!
• And last but possibly not least, some charities have grown tired of waiting for some of the traditional fundraising database suppliers to provide viable, cost-effective new releases and versions which they need for their fundraising. And there are definitely a lower selection of viable options now from such suppliers than there were some years ago.

So are the CRM suppliers having it all their own way?
Certainly not. The traditional fundraising database suppliers for large/mid-size charities, companies such as Blackbaud, thankQ, ACS (ex-IRIS) etc, have also been selling their software, some with good volumes, and so although the CRM systems are denting their sales they still haven't overtaken them. At least not here in the UK. And on the lower end, AdvantageNFP Fundraiser, Harlequin, even KISSS still sell plenty of systems.

Similarly, it is not just Salesforce and Dynamics who are selling 'CRM' systems. CiviCRM, a "CRM" system created especially for NFPs, is definitely growing in popularity here in the UK and even more so worldwide (and I'm going to be dedicating a blog to CiviCRM in the weeks to come); Workbooks.com are becoming an interesting option having recently made several sales to the membership sector; and I hear occasional things about Zoho and vTiger, but not that much. Sadly, SugarCRM doesn't seem to have made the inroads into the sector which I thought it might do (unless anyone can tell me differently?).

What's Next?
So what does all this mean now to other charities who might be looking to replace their existing fundraising database? Is it really any different to a few years ago in terms of what they can get or expect from 'generic' CRM systems?

Well, yes and no.

Yes it is different in that they won't be trailblazing (so much) any more, and they can hear and learn about other charities' experiences. Yes, in that (some of) the resellers and partners implementing these systems are more fundraising savvy now and should offer better professional services. And yes in that the cloud (which many CRM suppliers are tied to) continues to grow in acceptance and popularity.

But No, in that, at the end of the day, it still comes down to what is right for each charity depending on their needs, and the technology is just one aspect of any such decision. As I have expounded many times, there is no point buying a cloud-based solution or a whizzy CRM database just because it is that if it can't deliver what you need to support your fundraising operations. And that hasn't changed. There are still good, solid options for fundraising packages and there are good, solid reasons for charities to buy those, as well as CRM solutions.

I'm going to be blogging a lot in the coming weeks about some of these considerations, and some of the lessons I've learned when helping charities procure and implement both CRM systems and traditional fundraising databases, and those lessons are equally as important - more so? - compared to the software you ultimately use.

Finally, one last thought for now: I think the number of viable, good fundraising database solution suppliers has shrunk in recent years, especially for larger charities, and one great benefit the CRM providers have done is given charities a whole new approach which they can at least consider - and that is definitely a good thing, whatever they end up actually buying.

Initial Thoughts on ThankQ's Acquisition by The Access Group

The Access Group (Access) have just announced that they have acquired fundraising database supplier, ThankQ. These are my initial thoughts on what this means to ThankQ users and to the UK NFP sector as a whole.

• Access' have existing NFP solutions which are already used by 500+ UK organisations but they do not have another "CRM" system which they sell to charities (although they do sell GoldMine, but that has fewer applications for NFPs). So at first sight, ThankQ could fit well into their portfolio. And because they don't have an existing fundraising database system, they won't be migrating ThankQ users to another system they already sell. So, that would seem to suggest they see it as a system they will continue to support. Which should be good news for ThankQ users.
• One of the potential issues which ThankQ did have as a company was that, despite their sales success, they were still a comparatively small company with lower staff numbers and a much lower turnover than their key competitors such as Blackbaud, IRIS et al (let alone Salesforce and Microsoft!). So they didn't have the same money or resources to develop their software as per their larger competitors. So, if Access are serious about incorporating ThankQ as a system which they intend to continue to promote to the NFP sector, then it might be that they could invest more to a larger R&D budget to the software. In which case, that could really help ThankQ and its user-base.
• Of course, one of ThankQ's main plaudits as a company was its flexibility and approach, which it was able to follow as a small, independent organisation. It will be of high interest to ThankQ's existing and new customers as to how that now pans out. I wouldn't see any reason as to why Access would necessarily change the fundamentals of that, but it would be foolhardy to think that they wouldn’t want to introduce some of their own methodology and culture to their new group member. Like any acquisition, we shall have to see what is good or bad about that.

But how does this impact the UK NFP sector as a whole in terms of fundraising/CRM database suppliers?
ThankQ are (were) certainly one of the more successful, completely independent companies who purely sold just one fundraising database, so it didn't take a futurologist to predict an acquisition could eventually happen. And of course what we have seen over recent years are the larger players in the market buying their competitors; Blackbaud, IRIS and ASI being the obvious examples as well as others like TSG and Miller Technology. Some products have remained within these companies' portfolio but others have not, or have not had the same commitment to their on-going development. Which in some instances has meant less choice for charities.

So it has to be said (unless there is some other reason for Access' acquisition of ThankQ, or unless Access are now about to go on a spending spree and buy other similar systems - and I have no reason to believe that either of those issues is the case) that this acquisition should be no bad thing for the sector. A good database should hopefully remain a good database and a strong competitor but possibly now with more investment. I hope I'm right.