Should organisations choose a CRM platform before a supplier?

 

With the emergence of the generic CRM systems and the reduction in the number of viable proprietary fundraising databases, an interesting question is arising: should charities now be choosing a CRM platform before even looking at which specific supplier/partner they want?

It is a process which some companies in the commercial sector have already been practising for years. For some companies, they will decide first on whether Salesforce, Microsoft Dynamics, SugarCRM etc are the best fit for them, and only then will they search for a specific partner who can help them implement a new CRM system on that chosen platform.

For charities, however, at least until recently, because the options have primarily been about comparing different proprietary fundraising database suppliers (e.g. Blackbaud, thankQ, Redbourn, ACS etc), this has not been an approach we have taken. That said, there will of course have been some technological decisions: the system must be SQL Server, or it must be Oracle; it must be dot net or it must run on Linux etc. Or even, it should be open-source. And so on. So it's not a completely alien idea.

It's just that with the new CRM systems, the platform choice can be far more "business-oriented"; i.e. if we do decide that platform X is the right solution for us - and if that platform is one of the generic CRM systems - then we now have the choice of talking to numerous companies about how they would implement that, looking at whether we want a templated version or start out-of-the-box, develop in-house or with a partner, and so on.

But additionally, if as a charity you do want to be considering a platform first, you also need to consider the proprietary solution as one of those platforms - and (probably) not just one such solution but the concept as a whole. As I have discussed many times in my blogs, there is no simple right and wrong as to whether you should select a traditional fundraising database or a CRM solution. If you do select a proprietary solution then you will (almost certainly) implement it with that system's software author and that has its pros and cons. If you go with a CRM solution, then using a business partner of that software author (or even doing it in-house) also has its benefits and downsides.

Personally, at the moment, I think choosing a platform first is a difficult approach to take for all but a few, probably larger charities who already have a detailed, well thought through technology plan and IT strategy. Especially at an early stage in a procurement project when you are still trying to understand the differences, the benefits of all solutions, the impact on your organisation and so on. I think there would have to be clear reasons for you to only look at the traditional fundraising databases, or decide not to look at those at all. You might dismiss one option or one supplier etc as you progress your procurement, but I believe you need to understand what all options can offer before going solely down one route. So at the moment that will usually mean keeping them all in the hat until you are ready to shorten your choices to the final few.

The Importance of Report Designers during CRM Implementations

 

On one project I worked on, not long before we were due to go-live, there was some concern that a specific, highly important report could not be produced because of the fundamental, underlying design of the CRM system. And it made me wonder how this could have happened - that such an important factor had not been fully considered until that point. It turned out that the reason was because when the database was being designed, the report designer - i.e. the person who creates the reports, not the software - had not been consulted when they could have provided invaluable input.

When I thought more about this, my first reaction was to think that this should hopefully be a rare occurrence. One would trust that in most instances, whoever was designing the database - whether a person, a team, a company etc - would know the key reports which were required and would thus design the database so that such reports could be created. Plus, in classic systems design, one often starts with asking what reports and information are wanted and thus we work backwards to work out what fields and data need to be recorded in order that such reports can be created.

However, with larger or more complex implementations, with projects with larger teams, and also with the new CRM systems which now offer so much more flexibility with their design, I've realised that such a requirement could easily slip through a hole. It is quite feasible, if the correct person is not consulted, that a database could be designed without true understanding or consideration of some reports. Or perhaps understandably, whoever is designing the database was told by a 'third party' as to what a report needed to show, and thus they hadn't got the full picture.

This issue can also be exacerbated when a charity is implementing a new database where no-one in the charity necessarily has the in-depth experience of report creation on that system. (By the way, in this instance the charity may have to hold their hands up to accept their share of guilt as this isn't necessarily something which should be aimed purely at the supplier...)

So my advice:

• when designing databases, do make sure reports are considered early in the design phase;
• engage the relevant report designers as soon as possible, and if you don't have one in-house then consider contracting one even for a short period to do some 'sense checks' early on; 
• introduce a specific 'report workstream' in the project so that reports, outputs, mailings et al are specifically considered at all times; 
• and don’t underestimate the time or importance of this factor.

After all, if we can't report on the data or get the data out of the database in a useful format, why are we using the database in the first place?

Good Database Managers Know When to Say No

 

It is quite an art saying No. Especially when you are a database manager and your users are continually asking you to do this and that and everything else, and you know that, yes, that latest request is technically possible (as opposed to something just not being possible at all) but, business-wise, data-wise, policy-wise, it is the wrong thing to do...

So, do you say No in such instances?

I applaud any database manager who does say No when they truly believe that it is the wrong approach to take. But it's a hard thing to do. ^†

Of course, what I hope a database manager can say sometimes is, "No, but…" i.e. no, what you are asking should not be done that way, but on the other hand, you can do it this way. And then hope that most users will understand and appreciate that. An example is how someone might ask for a new field or new code table to be added to a database, when you know that it is better practise to extend the use of an existing field/table.

But it's harder when the question doesn't necessarily have such an easy answer. e.g. Can we add a new screen to show data item x to department y… Can we import these z records from another system…

Both may well be possible technically. You might well be able to create a new form so that department y has a specific view of some data, but if that means that they won't see other relevant data which they should be aware of, or if it means it will be much harder to maintain in the future, then you might need to say No. And although you can explain why not, there isn't such an easy answer to what they can do instead - it might just be that it shouldn't be done full stop.

Similarly with importing records from another database. What for? Who will use them and how often? Will those records still be on another database - if so, how will you keep them all up-to-date? And so on. I have seen countless systems littered with useless records which have been added some years ago just because someone had the bright idea of doing this one particular project…

So stick to your guns, database managers. Remember what Zammo said (for those old enough to know what I'm talking about…)

---

† BTW, for any fundraisers reading this, who feel that their database manager is always saying No, then I feel for you too! They might be doing so for good reasons, but it could of course be a bad database you have or even a not so savvy database manager…
 

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.