Lessons Learned from Implementing Single Supporter Systems (Part 1)

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

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

Lesson 1: What is a Single Supporter System?

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

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

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

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

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

Lesson 2: Define a (Strong) Business Case

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

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

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

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

-         To define the functionality;

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

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

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

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

Lesson 3: Manage User Engagement

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

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

-         16 Ways to Improve User Buy-in, and

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

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

Lesson 4: We need to Define our Business Processes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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