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.

Learning From How a Toyota Supplier Saved $1 million by Updating Its Tech Infrastructure

 

My second post in an on-going series of blogs on lessons we can learn from commercial sector technology implementations.

---

A recent article on TechRepublic shows how Toyota supplier, AW North Carolina (AWNC) spent $1.2m on new Cisco equipment, which has led to significant savings for them. Few charities will invest that amount in a new CRM system, but some of the approach which AWNC took provides us with very useful ideas for the benefits which charities may get from new CRM implementations, often regardless of size.


1) "Downtime at AWNC costs $272,000 an hour, so it's crucial to get systems up and running as quickly as possible. Any downtime, particularly in shipping, is incredibly detrimental."

Okay, so it's unlikely that a CRM system being down for an hour at a charity would have quite such high costs! However, downtime due to a poor or unsupported system or inadequate IT infrastructure is not always factored in to a charity's view on whether they need a new CRM/fundraising system.

So consider: what would it mean to your staff if they couldn't access their database for an hour? Probably, it wouldn't be terrible for most fundraisers/staff, they could cope for that time, although Supporter Services would no doubt find it awkward for managing in-coming phone calls. But what about half a day? Now staff will be getting more anxious, a backlog of income processing might build up, supporter services are finding it more difficult and major donor fundraisers can't see their contacts' details. What about a full day? Much harder now: thank you letters might be delayed, management for a forthcoming event becomes much harder, and what would happen if that day happened to be the day when you were due to do your Direct Debit claim?

So it's not just the cost of a new CRM system - all this needs to be considered when looking at investment.

2) "As a result of the new technology, AWNC avoided maintenance costs on the old equipment of $1 million in the first nine months the system was in place"

Again, unlikely for most charities that they will save $1m in nine months due to replacing a CRM/fundraising system, but I have come across several NFPs who are paying existing suppliers ridiculously high annual maintenance costs for what they are getting, even without upgrades and developments. And/or they have to have specialist, higher paid staff for their current, old system because there are so few people who can support it. So even if it is going to cost you £x to invest in a new CRM system, what are your savings going to be in the first 12 months? (In the next 5 years?) Forget "possible extra income" benefits for a moment, these figures are hard cost savings.

3) "About 40% of the savings will be ongoing and realized annually."

We forget this sometimes, that savings (and benefits of course) will not just be the first year, but over the following five to seven years. So in addition to point (2) above on immediate savings, what other costs will be lowered or made more efficient by a new system? Lower staff costs? Or maybe, the same staff costs but those staff being far more efficient, productive and proactive? Time-savings from quicker processes? Time-savings (and better productivity) from simpler, quicker development tools? Development you can do in-house now rather than having to always go to an expensive software supplier?

4) "It was very clear... that the infrastructure was not keeping current with where the world had gone."

We're all aware that digital is where fundraising is going. Yes, there will still be plenty of 'traditional' or offline income coming in for some years to come, but that appears to be declining, and GDPR/DP issues could be forcing our hand in terms of reducing direct marketing. There is a point when you do need to review how and whether your existing CRM/fundraising system can support you and provide additional benefits with your future fundraising plans because of changes in the outside world.

5) "It's common in a manufacturing plant to avoid buying new equipment in a misguided attempt to save money, with IT teams not realizing that the operational costs to troubleshoot problems and the associated downtime in a factory environment can result in even higher costs."

I love this! How many of you have suffered from this problem with your antiquated or unsupported fundraising databases?! (And it's kind of reassuring that commercial organisations have this problem too!)

6) "The big push for last year was solidifying the environment, and this year is all about pushing out into the applications and into the manufacturing space to impact yield inventory."

This is just a small point to show that any new CRM implementation does not have to be rolled out to everyone or to manage all potential benefits immediately. Plan for future expansions in the subsequent years after your immediate go-live - you don't need to, and shouldn't try to do everything on day one.

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.

What Small Charities Need to Know About CRM Systems – 2nd Version

I have updated my free ebook, What Small Charities Need to Know About CRM Systems. Buying a new CRM system or fundraising database can be a daunting experience for any NFP organisation, let alone a small charity. So although I publish a lot of information on my blog which I hope is useful for all charities, this book contains some points which I think smaller not-for-profit organisations need to particularly be aware of or specifically consider.

As before, this book has been produced for people whose day job is not the procurement or implementation of new databases – which for small charities is probably almost everyone! And you do not have to be technical to understand it. It is for fundraising managers, chief executives, trustees and fundraisers, but of course I hope it is equally useful for database staff and charity IT staff too.

This second version has a brand new section on System Development and updates throughout the rest of the book to reflect my latest thoughts and the software options now available to the sector.

Click here to download the PDF for free.