Lessons Learned from Implementing Single Supporter Systems (Part 2)

This is the second part of a blog post on the lessons I've learned as a project manager, implementing single supporter systems at a number of charities over the last few years. You can see part one here if you haven't already read it.
 

Lesson 5: Four Technology Lessons

As I mentioned, the technology within your new system may be the simpler bit, but that doesn’t mean to say it is always simple! And, as per a common theme of this post, there are of course many, many technological lessons to learn from implementing Single Supporter Systems; but here are 4 key lessons:

i)                    Keep it Vanilla. Fundamentally, what this means is that, as much as possible, you implement the database in the first instance without any - or with minimal - “Customisation”; although “Configuration” is fine. There are just so many great benefits which you will get from doing this, such as: improving the simplicity of implementation, lower risk, a faster implementation, a lower cost implementation and much more. I have written a whole separate blog post on Keeping it Vanilla, so please do go read it if you want to learn more!

ii)                   Data Migration is tough, but it is just technology. Again, I have written a brief, separate post with my top 3 data migration lessons, but because you could be migrating data from multiple source systems into your new single system, it has to be something you take very seriously.

iii)                 Integration is tough. In fact, it can be the most difficult technology part of some Single Supporter Systems. Everything from database/web integration and integrating with third party software, through to integrating data feeds in from other sources (e.g. fulfilment houses, third party web sites) and passing data through to other systems (e.g. finance systems). So, my advice is start on these as early as possible in the project, get your supplier involved or a dedicated expert who can work on this, and see such integration as a specific work item within your implementation; i.e. do not treat it just as yet another task which has to be done. It is of course, but it is highly likely to be a much harder one.

iv)                 Implement reporting in the initial implementation. I have been part of projects where this has been done and where it has not been done, and there is no doubt that the better approach is where it was actioned. It is such an important part of the initial implementation and of having the system at all – after all, there is no point in having a database if you can’t get the data out! But, it is often easy to overlook or forget. I would even consider having the reporting requirements as a separate workstream within the project.

Lessons 6: You need a Project Manager

I’m hoping this is something I shouldn’t need to say, but just to make sure: you need a Project Manager. And unless your Single Supporter System is remarkably small, you need a dedicated Project Manager. Because your implementation will take time, effort, co-ordination, liaison with many interested people and parties and a heck of a lot of work; and it just isn’t possible to do that for any significant system without a dedicated individual.

For more thoughts, on this, read my post on the Top 10 Benefits of Project Management.

Lesson 7: Just because you now have a joined-up, Single Supporter CRM system, does not mean you can now do joined-up CRM.

So you have your completed Single Supporter System, which of course means you are ready to “do” centralised CRM, yes? Well, no. Because although your new system will of course give you the tools to manage your contacts centrally, it does not mean you are ready and have the processes and protocols in place to implement this.

It’s all about the Change Management.

The best example I can give is this: if previously, your different departments or teams were all writing to and emailing their contacts without worrying about what the other departments/teams were doing, then this won’t change automatically just because you have a new system. You will still need to literally sit down and discuss this and plan your communications and contact management strategy from a centralised point of view. And it won’t necessarily be easy!

So, again, plan ahead, plan separate Change Management streams within the project, recognising that the technology is the deliverer and driver and not the creator of answers. That is down to that good ol’ fashioned thing called human decision. Although of course we hope that the new system can support and implement such decisions – that would certainly be quite nice…