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.